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 78400

Article: 78400
Subject: Asynchronous Inputs Question
From: daveb_24_7@yahoo.co.uk (Dave)
Date: 31 Jan 2005 09:33:49 -0800
Links: << >>  << T >>  << A >>
Hi,

I am implementing a state machine in a FPGA using VHDL.
Several states are determined by 4 external event inputs (falling
edge) which occur asynchronously to the 25MHz FPGA clock (I might need
to increase to 50MHz). The events occur at random intervals of 10us or
more.

I have a couple questions which someone may be able to guide me on:

1) Should I have a synchroniser (2-stage shift reg) at each of the 4
event inputs before being sampled by the state machine to avoid
meta-stability problems?

2) I'm using the following VHDL code to detect a falling edge on the
event inputs. Is there a better way?

process( clk, ev1, ev2, ev3, ev4, reset)
  variable prev_ev1: std_logic;
  variable got_ev1: boolean;

  <variables for other events omitted>

  begin
    if (reset = '1') then          -- reset the event states
       prev_ev1 := event;
       got_ev1 := false;
    elsif (rising_edge(clk)) then
       if (event = '0') then       -- event signal is low
          if (prev_ev1 = '1') then
             got_ev1 := true;      -- falling edge detected
          end if;
          prev_ev1 = '0'
       else
          prev_ev1 = '1';
       end if;
       
       <repeat edge detection for the other events>

       <process 'got_ev' flags in state machine & reset them> 
    end if;
end process;
             
Any advice welcome!
Thanks
Dave

Article: 78401
Subject: Re: Init of BRAMs with ISE flow.
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 31 Jan 2005 18:34:53 +0100
Links: << >>  << T >>  << A >>
"Rick North" <nobbe@acc.umu.se> schrieb im Newsbeitrag
news:4bbdba0c.0501310902.4dc320b1@posting.google.com...
> Hi All,
>
> I have several BRAMs in my design each needs its own set of constants.
> So far I have used the ucf file to store my BRAM values. But it has
> become error prone and tedious. I would like to have a command for the
> ucf such that I can "link" a generated file in to the ucf and its
> format.
>
> Something like:
> MyBRAM => file:MyBramFile.dat
> where MyBramFile contains
> "
> 0000002800000028000000280000002800000028000000280000002800000028
> 0000002800000028000000280000002800000028000000280000002800000028
> "...etc
>
> is this possible in some way?

Use data2mem utility. It can directly write BRAM content into a BITFILE, so
after the complete implementation process. Very nice feature when you
develop a FPGA based uC application (Picoblaze, Microblaze whatever)
This tool nees a special data file, (*.mem) but its very easy structured

Just a start address like
@0000

AA, BB, CC, DD etc.

Very easy to generate via a script/tool.

Regards
Falk



Article: 78402
Subject: Re: lowest-cost FPGA and CPLD
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 31 Jan 2005 12:35:17 -0500
Links: << >>  << T >>  << A >>
Johnson Liuis wrote:
> I heard that Lattice Semiconductor Corporation boasted they were providing
> the lowest-cost FPGA and CPLD solutions, not sure if the news was true.
> Could anybody confirm it? If so could anybody give me a price range for
> their lowest-cost solution?
> 
> I always have an impression that Xilinx provided the lowest-cost chip while
> Altera provided the high-performance one, is it still true? How is the
> Lattice compared to Xilinx and Altera?
> 
> Thanks.
> 
> Johnson
> 
> http://www.latticesemi.com/products/index.cfm

Claims like "lowest cost" or "highest performance" are pretty 
meaningless in the context of designing with an FPGA.  No matter what 
they  measure or how they measure it, unless they are using your exact 
design, it is not valid for your needs.  Also, the advertised price is 
almost never a price you will actually see.  Its a bit like automobile 
prices.  They advertise a super low price on the model sitting in the 
back of the lot in the avocado green color with the diesel engine and 
the vacuum powered wipers.  But if you want a car you can drive home, 
its going to cost a "little more".

I think they all have pretty good products and when it comes to pricing, 
you are on your own to get whatever price you can from your distributor; 
although I did once get better pricing by showing a sales rep an ad that 
claimed some price superiority on a new family line.  When I later tried 
to do a little better on the same part in a smaller package I was told 
that they could not improve on the previous quote because I was already 
getting the 50k price on quantity of a few k per year.  Interestingly 
enough, this 50k price was still more than a factor of 3 higher than the 
advertised price for 250k per year.  I guess its not until you start 
using a full production line capacity that you get the *real* price 
breaks...  ;^)

-- 

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design       http://www.arius.com
4 King Ave.                               301-682-7772 Voice
Frederick, MD 21701-3110     GNU tools for the ARM http://www.gnuarm.com

Article: 78403
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Peter Alfke" <peter@xilinx.com>
Date: 31 Jan 2005 09:38:45 -0800
Links: << >>  << T >>  << A >>
Don't forget, it's tomorrow, Tuesday, at noon Pacific Time.
Altera Marketing has e-mailed me and promised their attendance.
I will not disappoint them.
So join me tomorrow for some serious and fun talk on FPGA performance.
Peter

> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:1106877046.479990.51180@z14g2000cwz.googlegroups.com...
> >
> >
> > If you click on
> >
> > http://seminar2.techonline.com/s/xilinx_feb0105
> >
> > and register for the Feb.1 Xilinx TechOnLine, then you can witness
my
> > presentation about Virtex-4 performance. It's a daring high-wire
act
> > between engineering and marketing. Wish me luck!
> >
> > The time is Tuesday, Feb 1, noon to 1 pm Pacific time.
> > It would be nice to feel that I can count on some friends in the
> > invisible audience.
> >
> > Peter Alfke, Xilinx Applications
> >
> 
>


Article: 78404
Subject: Re: LVDS without termination
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 31 Jan 2005 10:05:04 -0800
Links: << >>  << T >>  << A >>
Hi Gabor,
I think the point is, that with tiny loads on the output, i.e. small traces,
the outputs swing very quickly to whatever voltage the current sources can
provide. This probably remains within the range of the FPGA's diff inputs,
they're very good and wide. I don't see how having 'guaranteed AC content'
makes any difference. Could you explain what you mean by that? Do you mean
enough edges, or no DC?
As you say, I'd certainly have to try it first, the datasheet is not clear
on the output structure. See appnote HFAN-01.0 from Maxim for an overview of
their output structure. Dunno what the Texas one looks like.
On the other hand, I'd be very nervous about doing this. Especially with an
enormous 80 pin PQFP package driving the outputs. Again, think of the
hideous leadframe. Like you say, you'd have to prototype it first.
Kolja,
You do know that you can get 8x100 resistors in two packs sized 2x1mm? Rohm,
AVX, Koa etc.. have gone to a lot of trouble to make these bits. Use them!
http://www.avx.com/docs/Catalogs/crb-crc.pdf
And fix your PCB technology, your competitors will!
Cheers, Syms.

"Gabor" <gabor@alacron.com> wrote in message
news:1107179024.417762.98680@f14g2000cwb.googlegroups.com...
>
> > at these very short signal lengths. What I am concerned about is the
> > current mode driver characteristic as described by Gabor.
> What bothers me about leaving out terminators, especially in your case
> where you're not running 8b/10b or some other code with guaranteed
> AC content, is what happens when the output has been in one state long
> enough to generate a wide voltage spread.



Article: 78405
Subject: Re: =?ISO-8859-1?Q?ProASIC=A7_Released?=
From: Ben Popoola <ben.popoola@REMOVE.recontech.co.uk>
Date: Mon, 31 Jan 2005 18:30:09 GMT
Links: << >>  << T >>  << A >>
Jedi wrote:
> Luc wrote:
> 
>> No, no,
>>
>> It is called XP, based on 130nm flash tech from fujitsu.
>> Performance-wise like the EC,and non-volatile like the ispXPGA. But
>> this was EČ, and therefore a lot more expensive. You can expect the XP
>> in the price range of the EC.
> 
> 
> Actually price range will be EC + external SPI flash (o;
> 
> 
> rick
> 
> 
>>
>> Regards,
>>
>> Luc
>>
>> On Thu, 27 Jan 2005 11:09:52 -0800, "Antti Lukats"
>> <antti@openchip.org> wrote:
>>
>>
>>> ispXPGA? those are "old" stuff it was available long time before 
>>> EC/ECP was announced, I did think jg was referring something new, eg 
>>> not-announced lattice product...
>>>
>>> antti
>>
>>
>>

I think that the XP replaces the "DSP blocks" in the ECP device with 
flash (EEPROM) memory blocks for storing the configuration bits.

Ben

Article: 78406
Subject: Re: Asynchronous Inputs Question
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Mon, 31 Jan 2005 18:30:44 +0000
Links: << >>  << T >>  << A >>
On 31 Jan 2005 09:33:49 -0800, daveb_24_7@yahoo.co.uk 
(Dave) wrote:

>I am implementing a state machine in a FPGA using VHDL.
>Several states are determined by 4 external event inputs (falling
>edge) which occur asynchronously to the 25MHz FPGA clock (I might need
>to increase to 50MHz). The events occur at random intervals of 10us or
>more.
>
>I have a couple questions which someone may be able to guide me on:
>
>1) Should I have a synchroniser (2-stage shift reg) at each of the 4
>event inputs before being sampled by the state machine

Yes, absolutely, unless you have an astonishingly cunning state
machine design...

> to avoid meta-stability problems?

AARGH, no, that's not the reason.

Saddle-up the old warhorse, and back in to battle once again...

Most people who *think* they have a problem with metastability,
don't.  Instead they probably have a problem with input hazards.

OK, so what's an input hazard?  It's any situation where an
asynchronous input can affect more than one flip-flop.

If this asynch input should change painfully close to a clock
edge, you will of course get setup/hold violations on the flops.
This in itself rarely causes a problem, because each flop 
individually will either respond to the changed input or it
won't.  The problem happens when one of the flops DOES respond,
and the other DOESN'T.  When this happens you get an internal
state change that was not expected.  It will almost certainly
screw up the sequencing of your state machine, and it will
quite likely send it off into the weeds.

Note that, in describing this problem, I have made no appeal
whatever to the idea of metastability.  Each flip-flop
individually is behaving quite perfectly;  it's just that
the collection of two flip-flops appears to behave inconsistently
because of the asynchronous input.

The problem is completely (yes, I really mean completely) solved
by registering the offending input in just one flip-flop.  
The output of this resynchronising flop is then fed to your 
state machine.  Given that the input is asynchronous, a one-
clock delay in responding to it is unlikely to be a show-
stopper.

If you are both clever and lucky, you may be able to design
your state machine so that only one of its state bits is
affected by any input change.  However, it is brain-
numbingly difficult to do this in the face of complicated
changes to the state machine as its design evolves, and
when synthesis tools are inclined to re-code state
vector values arbitrarily as an "optimisation".  So it's
almost always better, in practice, to register the 
asynchronous inputs before they get anywhere near your
state machine.  Especially when you have multiple asynch
inputs to worry about.

Metastability is a much less likely culprit.  Metastability
means that one individual flop misbehaves because its D input
changes at an inopportune moment, so that the internal
logic of the flop gets confused about whether to settle at
1 or 0.  The flop's clock-to-output delay then becomes much
longer than its specified value.  This effect, of course,
CAN happen on my single resynchronising flop, and CAN cause 
trouble if its clock-to-output delay is thereby pushed out
to about a clock period;  should this happen, the supposedly
resynchronised signal can itself appear to be asynchronous and
can therefore cause an input hazard on the state machine.
A second resynch flip-flop will dramatically reduce the risk
of this problem, at the expense of one more cycle of latency.
Figures published here by Peter Alfke and others suggest that
in your case, with a slow-ish clock and relatively infrequent
transitions of the asynchronous input, the risk of this
genuine metastability is so small that you can ignore it - 
but you MUST either do the sums, or else be just a little
paranoid and add the extra flop in any case.

>2) I'm using the following VHDL code to detect a falling edge on the
>event inputs. Is there a better way?
>
>process( clk, ev1, ev2, ev3, ev4, reset)

Oh flippin' 'eck, what are you doing putting asynch 
inputs into the sensitivity list of a clocked process?

>  variable prev_ev1: std_logic;
>  variable got_ev1: boolean;
>
>  <variables for other events omitted>
>
>  begin
>    if (reset = '1') then          -- reset the event states
>       prev_ev1 := event;
>       got_ev1 := false;
>    elsif (rising_edge(clk)) then
>       if (event = '0') then       -- event signal is low
>          if (prev_ev1 = '1') then
>             got_ev1 := true;      -- falling edge detected
>          end if;
>          prev_ev1 = '0'
>       else
>          prev_ev1 = '1';
>       end if;
>       
>       <repeat edge detection for the other events>
>
>       <process 'got_ev' flags in state machine & reset them> 
>    end if;
>end process;

Yeah, something like that.  Don't reset the flags inside 
the state machine.  Reset them at the top of the clocked 
process, so that they become purely combinational flags.
Effectively you've created a shift register with
an and gate sensing a change across its final stage.  

It's sometimes easier to roll this edge detection
into the state machine (don't go into your "wait for fall" state
until you've detected "input high").  Depends on what you're
doing in the state machine.  Once again, given that you have
multiple inputs, I suspect the scheme you outline is as good
as you'll get - and it's easy to understand.
             
>Any advice welcome!

Finally, please DON'T do anything that depends on 
simultaneity of two or more of the external asynchronous
inputs - you simply can't rely on that, given that they
are asynchronous relative to your clock.  The best you 
can do is to identify when two or more inputs change
within one or two sampling clocks of each other.  
Alternatively, if you're very lucky you may have an
external signal that indicates when the four inputs
are stable and therefore it's safe to sample them.

HTH
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223          mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


Article: 78407
Subject: Re: Master Serial Programming
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Mon, 31 Jan 2005 18:35:42 +0000
Links: << >>  << T >>  << A >>
sowjanya_sn@mindtree.com wrote:

>Hi ,
>I have general question regarding the Master Serial Programming
>mode .
>In the Master Serial Programming mode , FPGA drives the clock . But ,
>how will the FPGA know that there is relevant and complete data present
>on the PROM . Is there any mechanism to tell the FPGA that the
>configurable data is present on the PROM and FPGA to initiate the
>clock.
>
In just a few words, the FPGA doesn't know at the begining if the prom 
has "relevant" (and it doesn't have to know) data it just run the clock 
enable the prom (INIT->\CE) which resets the internal counter inside the 
prom and the prom will start to  shift  out the bitstream. The FPGA will 
parse  the  incoming bitstream to detect  a valid header (0xFFAA55 not 
sure if this is correct - just check the docs) and everything following 
this sequence is considered bitstream for the configuration mechanism 
(and will count for the CRC check)

Short: in master serial mode the fpga is assuming that the prom has the 
bitstream already.

Aurash

> 
>
>Thanks in Advance , 
>Sowjanya
>
>  
>


-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     


Article: 78408
Subject: Re: Init of BRAMs with ISE flow.
From: "Moti" <moti@terasync.net>
Date: 31 Jan 2005 10:49:40 -0800
Links: << >>  << T >>  << A >>
There is a very friendly and easy to use tool called "memory editor"
and it's located in the core generator application. It will make your
life alot easier...
Regards, Moti.


Article: 78409
Subject: Re: Design security
From: "Martin" <0_0_0_0_@pacbell.net>
Date: Mon, 31 Jan 2005 19:22:36 GMT
Links: << >>  << T >>  << A >>
"Nicholas Weaver" wrote:

> Physical/corporate security is a PITA, depending on one's level of
> paranoia.
>
> for the properly paranoid, working at home is definatly NOT allowed.

I'm not sure that paranoia is involved here, but rather, reality.  Yes, 
paranoia might be an element, but not an overwhelming one, at least in my 
opinion.  The question I posed might be considered a mental excercise rather 
than a quest for a full solution.  I know that the real solution would be 
horribly complex and constraining from just about every angle.  We are 
talking government-grade security with threat of prison...and even that 
doesn't work 100% of the time.

An example of reality might be hiring an offshore team for some design work. 
How can you even approach securing that design?  I don't think that it is 
possible.

As a small company, I must admit, from time to time there exists a concern 
about having valuable design data that should be private become exposed to 
"the elements".  Not necessarily maliciously, but rather, accidentally.

Example: You travel to a conference for a few days and take your laptop 
along to continue working on the project.  You forget that you have some 
shares enabled.  Upon plugging into the hotel's network your files are 
exposed to other industry folk staying at the same hotel.

The ONLY experience we've had with "data migration" did not involve design 
files but rather a $10K CAD system software that was stolen (CD duplication) 
by an engineer on his way out.  For a small company this is quite painful. 
Taking someone to court over this is both expensive and futile.  What are 
you going to do, make the guy erase all of his copies?  Impossible.

Anyhow, it would be interesting to find a simple methodology to enhance 
design security rather than to lock down all avenues of escape.  One such 
idea is to use a encrypted file system.  www.ntfs.com has a bit of 
information on Windope's EFS.  It seems to me that this might (and a big 
"might") serve to prevent simple copies of files onto various media (or 
transmission --hotel scenario--) from being of any use.  Of course, we have 
to remember that we are dealing with engineers here...

-Martin




Article: 78410
Subject: Re: spartan3 starter kit now comes with eval version of edk
From: Carsten <xnews1@luna.kyed.com>
Date: Mon, 31 Jan 2005 20:44:39 +0100
Links: << >>  << T >>  << A >>
>
>"Alex Gibson" <me@privacy.net> wrote in message 
>news:365ps8F4sc51gU3@individual.net...
>> http://www.xilinx.com/products/spartan3/s3boards.htm#edk
>>
>> Is there any where to download the eval version of the edk
>> if you already have a spartan3 starter kit ?
>>
>> Alex
>>
>
>or to get an evaluation cd  ? 

I did ask Xilinx about this and just got this ansver from 
"online store"

 **** Quote  *****

The EDK eval is being sent to all who have purchased the Spartan 3
Starter kit and will begin shipping within the next couple of weeks.

 **** End Quote  *****

Thank you Xilinx , for an excellent service :-)

Rgds
Carsten
Denmark

Article: 78411
Subject: Re: =?ISO-8859-1?Q?ProASIC=A7_Released?=
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 31 Jan 2005 15:09:57 -0500
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Antti Lukats wrote:
> 
>> Hi Jim,
>>
>> any more about this lattice info I mean of what you can say ;)
> 
> 
> Hi Antti,
> 
> Well, this was the info released on Sept 10th :
> 
> "In addition, Lattice has recently received the first 130nm Flash-based 
> products and the first 90nm products fabricated by Fujitsu, which are 
> currently in the early stages of evaluation."
> 
> These are the ones comming after the already released EC/ECP FPGAs.
> 
> Actel say Q4 for production, so there is time for Lattice to come
> to the party.

I'm not sure what party you are referring to.  Lattice already has 
flash/SRAM parts that combine the best of both worlds.  They are not as 
cheap as these however.  Is that what you mean, the low priced parts?



> and no serial load, you have to consume FPGA fabric to init...

That pretty well sucks.  I guess the cost of initializing the sram from 
flash was more than they felt it was worth.  But it really does put a 
damper on the CPU core thing.  Now you have to add back the external 
Flash.


>> and that the FROM (1k flash array) is not writeable from FPGA only 
>> from ext JTAG
> 
> 
> that's somewhat understandable.
> Still, 1K is probably (just) enough to include a tiny-boot-load, so a 
> MUX is not needed in the critical RAM path of a SoftCPU.

But you *do* need a mux in the even more critical instruction fetch path 
of a core CPU.  These parts are also a bit light on ram.  Even the 
A3P1000 only has a bit over 16 kBytes.



> Good package ranges, but why only the smallest in MLF132 ?
> ( die too large on the others ? )

That's a pretty classic issue with FGPAs.  Only a few users want the 
larger parts in low pin count packages.  Otherwise they would make low 
pin count parts and save the die area used for IO.

-- 

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design       http://www.arius.com
4 King Ave.                               301-682-7772 Voice
Frederick, MD 21701-3110     GNU tools for the ARM http://www.gnuarm.com

Article: 78412
Subject: Re: i need xilinx edk
From: pratipm@hotmail.com
Date: 31 Jan 2005 12:10:47 -0800
Links: << >>  << T >>  << A >>
What are the limitations of the Eval version? Is it time limited or
feature limited?
Thanks.

Alex Gibson wrote:
> "DJ" <reconfigurablecomputing@gmail.com> wrote in message
> news:1107033515.069539.84000@z14g2000cwz.googlegroups.com...
> > hi all
> > does anyone have a cracked copy of xilinx edk....
> > can you help me getting it..?
> >
> 
> Go buy a xilinx spartan3 starter kit and get the eval version


Article: 78413
Subject: FPGA configration Data/Firmware
From: jdy0803@hotmail.com
Date: 31 Jan 2005 13:14:30 -0800
Links: << >>  << T >>  << A >>
Hi all

I have no idea regarding low level hardware.
I should firgure out something about ALTERA ACEX.
Question is like following.

1.Are the FPGA configuration data and the firmware different?
2.How can I extract FPGA configuration data from ALTERA ACEX to my PC?
3.How can I extract firmware in EEPROM to my PC?

P.S
What I want to do finally is extrating data from FPGA and EEPROM and
then copy to another fresh FPGA/EEPROM.


Article: 78414
Subject: Active HIGH / Active LOW
From: muthusnv@rediffmail.com
Date: 31 Jan 2005 13:18:54 -0800
Links: << >>  << T >>  << A >>
Hi,
There chips with the mixture of Active HIGH and Active LOW signals. Is
there any pros and cons of each levels? OR it simply choice of
designers / manufacturers?

Thanks in advance.

Regards,
Muthu


Article: 78415
Subject: Re: LVDS without termination
From: "Gabor" <gabor@alacron.com>
Date: 31 Jan 2005 13:28:01 -0800
Links: << >>  << T >>  << A >>

Symon wrote:
> Hi Gabor,
> I think the point is, that with tiny loads on the output, i.e. small
traces,
> the outputs swing very quickly to whatever voltage the current
sources can
> provide. This probably remains within the range of the FPGA's diff
inputs,
> they're very good and wide. I don't see how having 'guaranteed AC
content'
> makes any difference. Could you explain what you mean by that? Do you
mean
> enough edges, or no DC?
My point is that whether you model the lines as 50 ohm transmission
lines
with some finite delay, or as a lumped capacitive load, you will see
that
a current source switched into this net provides a slew-rate limited
output.  The slew rate should come directly from the current value and
the effective capacitance.
So if you had an ideal current source that never clipped, and didn't
have a DC balanced code, you would slowly integrate to one state or
another
and never return to the zero crossing.  In the case of a
voltage-limited
source, the issue is how much longer does it take to reach the
crossover
threshold if the outputs have a 2V differential (no load case having
been in one state long enough to clip the current source) than it would
to reach the crossover from a 0.35V differential (nominal LVDS into 100
ohms).
If the slew-rate limits you to a value that you can't accept at 480
Mbps you will need the resistors, not for termination but to limit the
output voltage swing.  For a true current source for example at 3.5mA
going into 10 pF, you would slew at most 0.35V per nanosecond.  From
the data sheet specs like ISOUT NP (outputs shorted together gives
12 mA max) I would guess these "current outputs" are not true current
sources, so the slew time may not be that bad.  However if the output
were really limited to 3.5 mA you could see that trying to slew 2V
would put you out of the realm of achieving 480 Mbps.
You may find that the drivers don't behave this way, but putting pads
for the 100 ohm terminators (even near the source) would give you a
way out if they do.
> As you say, I'd certainly have to try it first, the datasheet is not
clear
> on the output structure. See appnote HFAN-01.0 from Maxim for an
overview of
> their output structure. Dunno what the Texas one looks like.
> On the other hand, I'd be very nervous about doing this. Especially
with an
> enormous 80 pin PQFP package driving the outputs. Again, think of the
> hideous leadframe. Like you say, you'd have to prototype it first.
> Kolja,
> You do know that you can get 8x100 resistors in two packs sized
2x1mm? Rohm,
> AVX, Koa etc.. have gone to a lot of trouble to make these bits. Use
them!
> http://www.avx.com/docs/Catalogs/crb-crc.pdf
> And fix your PCB technology, your competitors will!
> Cheers, Syms.
>
> "Gabor" <gabor@alacron.com> wrote in message
> news:1107179024.417762.98680@f14g2000cwb.googlegroups.com...
> >
> > > at these very short signal lengths. What I am concerned about is
the
> > > current mode driver characteristic as described by Gabor.
> > What bothers me about leaving out terminators, especially in your
case
> > where you're not running 8b/10b or some other code with guaranteed
> > AC content, is what happens when the output has been in one state
long
> > enough to generate a wide voltage spread.


Article: 78416
Subject: Re: Active HIGH / Active LOW
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 31 Jan 2005 13:34:56 -0800
Links: << >>  << T >>  << A >>
muthusnv@rediffmail.com wrote:

> There chips with the mixture of Active HIGH and Active LOW signals. Is
> there any pros and cons of each levels? OR it simply choice of
> designers / manufacturers?

I believe for TTL there is some advantage to active low for
enables and such.   TTL has much better current sinks than 
current sources.   I don't believe the advantage is as big,
if any, for CMOS but may have been kept for backward 
compatibility reasons.

-- glen


Article: 78417
Subject: Re: Active HIGH / Active LOW
From: "CWatters" <colin.watters@pandoraBOX.be>
Date: Mon, 31 Jan 2005 21:37:02 GMT
Links: << >>  << T >>  << A >>

<muthusnv@rediffmail.com> wrote in message
news:1107206334.599924.199870@c13g2000cwb.googlegroups.com...
> Hi,
> There chips with the mixture of Active HIGH and Active LOW signals.

> OR it simply choice of designers / manufacturers?

Yes the designer can define a signal to be active High or active Low - it's
his choice.

However...  In general P type devices switch slower than N type. This means
that many devices have slightly different rise and fall times - eg the fall
time 5V->0V is faster than the rise time 0V->5V. This means that if you need
a fast edge for a signal (lets call it a "Ready" signal) then you use the
falling edge because thats faster. Therefore its natural to define Ready =
True = 0V. That makes it an Active Low signal.







Article: 78418
Subject: Re: Active HIGH / Active LOW
From: "CWatters" <colin.watters@pandoraBOX.be>
Date: Mon, 31 Jan 2005 21:40:40 GMT
Links: << >>  << T >>  << A >>

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:ctm8dm$vib$1@gnus01.u.washington.edu...
> muthusnv@rediffmail.com wrote:
>
> > There chips with the mixture of Active HIGH and Active LOW signals. Is
> > there any pros and cons of each levels? OR it simply choice of
> > designers / manufacturers?
>
> I believe for TTL there is some advantage to active low for
> enables and such.   TTL has much better current sinks than
> current sources.   I don't believe the advantage is as big,
> if any, for CMOS but may have been kept for backward
> compatibility reasons.

I may be out of date but... it used to be the case that P type devices were
roughly half as fast as N type. They got the edges symetrical in CMOS logic
families by making the P channel FET twice the size of the N channel FET.



Article: 78419
Subject: Re: Design security
From: "Jezwold" <edad3000@yahoo.co.uk>
Date: 31 Jan 2005 13:48:18 -0800
Links: << >>  << T >>  << A >>
Dont fall into the trap of thinking that just because you are working
with engineers they will be able to circumvent any security
system,certainly there is no easy way of stopping data walking out of
an office.or being e-mailed out of an office ,so you have to minimise
the cost of the loss of that data or the cost of that data being known
to a competitor.You could not allow your engineers to go home or use
the phone or use the internat and your design would remain secure.


Article: 78420
Subject: Re: Design security
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 31 Jan 2005 14:00:47 -0800
Links: << >>  << T >>  << A >>
Perhaps that's why one of them ripped him off in the past... ;-)
"Jezwold" <edad3000@yahoo.co.uk> wrote in message
news:1107208098.133369.227150@z14g2000cwz.googlegroups.com...
> You could not allow your engineers to go home or use
> the phone or use the internat



Article: 78421
Subject: Temat:Re: Actel A54SX72A - FF with clear and preset? Necessary for triple redundant register
From: wzab@ise.pw.edu.pl (Wojciech Zabolotny)
Date: 31 Jan 2005 14:21:16 -0800
Links: << >>  << T >>  << A >>
Gabor wrote:

> Are you saying that the synthesis uses only C-cells, or C-cells in
> addition
> to R-cells.  Your fclr and fset inputs require gates, so an R-Cell
> could not
> implement the logic by itself.  I think in Xilinx you would use a LUT
> as
> well as the adjacent flip-flop to implement each bit.

Well it uses ca. 4 C-cells for each bit. The 8-bit redundant register
(requiring 24 single FFs) uses 98 or 100 C-cells! It is way too
much...

In fact the Actel documentation ("Actel HDL Coding Style Guide" -
http://www.actel.com/documents/hdlcode.pdf page 87) states:
[...]
Asynchronous Preset and Clear
This is the most problematic register for the ACT 2, XL, DX, MX, SX
and ACT 3 architectures. You can only use one cell (the DFPC cell) to
design an asynchronous preset and clear register. The DFPC uses two
CMODs to form a master latch and a slave latch that together form one
register. This uses two CMODs per register and offers no logic
combinability with the SMOD. The DFPC requires more setup time and no
combinability. The net timing loss can often be as high as 10ns. Actel
recommends that you do not use any asynchronous preset and clear
registers on critical paths. Use a synchronous preset with
asynchronous clear or a synchronous clear register instead. You can
use an asynchronous preset and clear register if it does not affect a
critical path or cause high utilization in the design.
[...]

However the above contradicts to the R-cell layout shown in the
datasheet, which I've quoted in the first post - the FF in R-cell is
equipped with independent Clear and Preset.
However, when I've inspected different synthesized project, I've seen
that always one of them was tied to ground, so maybe they are not
completely indepentent?

Well, if it is impossible to build such flip-flops with the R-cells,
and if the price of RT parts is unacceptable, what are the
alternatives?
Does anybody know if there are some data about radiation hardness of
eg. Altera Hardcopy devices??? I've tried to google them, but found
almost nothing...

-- 
Regards, Wojtek Zabolotny
wzab@ise.pw.edu.pl

Article: 78422
Subject: Re: Temat:Re: Actel A54SX72A - FF with clear and preset? Necessary for triple redundant register
From: "Gabor" <gabor@alacron.com>
Date: 31 Jan 2005 15:16:09 -0800
Links: << >>  << T >>  << A >>
Wojciech Zabolotny wrote:
> Gabor wrote:
>
> > Are you saying that the synthesis uses only C-cells, or C-cells in
> > addition
> > to R-cells.  Your fclr and fset inputs require gates, so an R-Cell
> > could not
> > implement the logic by itself.  I think in Xilinx you would use a
LUT
> > as
> > well as the adjacent flip-flop to implement each bit.
>
> Well it uses ca. 4 C-cells for each bit. The 8-bit redundant register
> (requiring 24 single FFs) uses 98 or 100 C-cells! It is way too
> much...
>
> In fact the Actel documentation ("Actel HDL Coding Style Guide" -
> http://www.actel.com/documents/hdlcode.pdf page 87) states:
> [...]
> Asynchronous Preset and Clear
> This is the most problematic register for the ACT 2, XL, DX, MX, SX
> and ACT 3 architectures. You can only use one cell (the DFPC cell) to
> design an asynchronous preset and clear register. The DFPC uses two
> CMODs to form a master latch and a slave latch that together form one
> register. This uses two CMODs per register and offers no logic
> combinability with the SMOD. The DFPC requires more setup time and no
> combinability. The net timing loss can often be as high as 10ns.
Actel
> recommends that you do not use any asynchronous preset and clear
> registers on critical paths. Use a synchronous preset with
> asynchronous clear or a synchronous clear register instead. You can
> use an asynchronous preset and clear register if it does not affect a
> critical path or cause high utilization in the design.
> [...]
>
> However the above contradicts to the R-cell layout shown in the
> datasheet, which I've quoted in the first post - the FF in R-cell is
> equipped with independent Clear and Preset.
> However, when I've inspected different synthesized project, I've seen
> that always one of them was tied to ground, so maybe they are not
> completely indepentent?
>
> Well, if it is impossible to build such flip-flops with the R-cells,
> and if the price of RT parts is unacceptable, what are the
> alternatives?
> Does anybody know if there are some data about radiation hardness of
> eg. Altera Hardcopy devices??? I've tried to google them, but found
> almost nothing...
>
> --
> Regards, Wojtek Zabolotny
> wzab@ise.pw.edu.pl

Don't know about Altera, but Atmel recently got into the Rad Hard
business:
http://www.atmel.com/ad/radhardfpga/default.asp?source=enews


Article: 78423
Subject: Re: Active HIGH / Active LOW
From: Georgi Beloev <gbH8SPAM@beloev.net>
Date: Mon, 31 Jan 2005 15:18:45 -0800
Links: << >>  << T >>  << A >>
muthusnv@rediffmail.com wrote:
> Hi,
> There chips with the mixture of Active HIGH and Active LOW signals. Is
> there any pros and cons of each levels? OR it simply choice of
> designers / manufacturers?
> 
> Thanks in advance.
> 
> Regards,
> Muthu
> 

Unconnected TTL inputs are interpreted as logic high. Hence it is more 
convenient to define the active level of control signals as logic low 
and allow the designers to simply not connect the pins carrying those 
signals if they don't need them. Also, if a cable is unplugged from a 
board the inputs read high (not active) and the board does not attempt 
to do anything unexpected.

Active low is also commonly used for signals with multiple drivers, 
e.g., interrupt request lines. In this case there is a pull-up resistor 
and open-collector or open-drain drivers that pull the singnal low.

My 2c.
-- Georgi

Article: 78424
Subject: Re: Using LM317S adjustable linear regulator for Spartan 3?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 31 Jan 2005 15:42:53 -0800
Links: << >>  << T >>  << A >>
I wrote, after being frustrated at not finding any cheap fixed 1.2V:
linear regulators:
> Is there any reason why using an LM317S adjustable linear regulator
> with 1% resistors wouldn't be satisfactory for the Spartan 3 power
> supplies, particularly Vccint and Vccaux?
[I later discovered that it won't meet the spec because the reference
(feedback) voltage may be as high as 1.3V.  Someone else pointed me to
the Sharp PQ012FZ 1.2V LDO, which is cheap but poorly documented.]

Anton Erasmus <nobody@spam.prevent.net> writes:
> Have you looked at the ON Semiconductor offerings ? They have quite a
> few regulators, at very good prices. I use the LM1117 Series quite
> often. It does not have a fixed 1.2V version, but it does have an
> adjustable one as well.

The National LM1117 and the On equivalent, the NCP1117, have the
same problem with reference voltage.  For On's part, the max is 1.27V,
which is too high because the Vccint maximum is 1.26V.

Admittedly this isn't out of range by much, and would probably be OK,
but I prefer to stick to proper engineering practice and use parts with
which I can guarantee that the specs are met.

The only obvious problem with the Sharp part is that the data sheet
doesn't specify the allowable characteristics of the output capacitor
(minimum/maximum capacitance and ESR).  For an LDO that seems fairly
important.

Eric



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