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 77925

Article: 77925
Subject: Re: LVDS through connectors
From: Georgi Beloev <gbH8SPAM@beloev.net>
Date: Thu, 20 Jan 2005 10:38:38 -0800
Links: << >>  << T >>  << A >>
James Morrison wrote:
> On Thu, 2005-01-20 at 05:00 -0800, Marc Randolph wrote:
> 
> 
>>I was figuring that someone would disagree with what I said - I just
>>didn't figure it would be within a half hour!
> 
> 
> Life is all about timing!
> 
> 
>>I was actually referring to the whole solution when I was referring to
>>the speed: signalling type (LVDS, which has slower edges than PECL and
>>CML), termination location (hopefully on-chip), voltage swing, etc.
> 
> 
> I don't disagree with what you've said and appreciate the insight from
> your past experience.  I guess what I was reacting to is the concept
> that the connector doesn't matter.  It does matter, but as I said, it
> all depends on how much margin you have in your design.  In a particular
> design it may or may not matter based on a hundred other factors.
> 
> As you mentioned, in a lot of ways differential signalling is a whole
> lot easier to deal with.  Of course there is no such thing as a
> single-ended signal.  Ground is typically the other end that happens to
> be common among all signals.

Thanks for the replies, they really help me get a better picture! I 
don't have TigerSHARCs, just two Spartan-3 FPGAs.

I wonder what is the acceptable mismatch between the traces of an LVDS 
pair? Given ~6 in/ns propagation speed and, let's say 0.2 ns rise time, 
the rise time length is 1.2 inches. Is something like 10% of that, or 
120 mils, acceptable trace length mismatch? I think it will be even 
lower than that when the final routing of the board is done.

Any thoughs about vias on the signal traces?

Thanks again,
-- Georgi

Article: 77926
Subject: Re: Comparison of LEON2, Microblaze and Openrisc processors
From: "Ulf Samuelsson" <ulf@NOSPAMatmel.com>
Date: Thu, 20 Jan 2005 19:41:50 +0100
Links: << >>  << T >>  << A >>
"Jim Granville" <no.spam@designtools.co.nz> skrev i meddelandet
news:41ef3cfd$1@clear.net.nz...
> Hal Murray wrote:
> >>Reasonably, such a chip will need to have an external flash memory
> >>and the pins between the FPGA and the Flash.
> >
> >
> > Good point, but... It depends upon the problem.
> >
> > Lots of interesting problems will fit into on-chip RAM.
> > They might fit better into a special purpose CPU.  That
> > costs more design time.

One of the few reasons why you would want to have a soft processor today,
is if you can boost your application through a non standard instruction set.

Why would you choose an FPGA with a soft Microblaze/Leon/OpenRISC
over an FPGA with a hardwired Microblaze/Leon/OpenRISC?

If you come to the conclusion that a hardwired Leon is better than a soft
one,
then you need to ask yourself, if it is very important having a Leon, or
will an external ARM7 chip do? The AT91FR40162 is 10 x 10 mm
so it is not a lot of board space yuou can save by just having an
external flash.

If you had a low cost coverification tool for the specific architecture
then it is easier to develop the FPGA, and this could be one motivation.
I have not heard about coverification for the cores mentioned above though.

A multichip package with flash and FPGA would make the proposal more
attractive
if you need certain combinations not available in std micros like PCI bus
enabled controller.
This would result in smaller board space.
You can of course do a multichip FPGA + Flash Micro, but market might be
smaller

> The PicoBlaze, and tiniest variant of NIOS are interesting forthis
>
> >
> > External serial flash will be horribly slow, but might be good
> > enough for some problems.  Only takes a few pins.  You could
> > use on chip RAM for a cache or load it explicitly (bank switching).

You mean an FPSLIC ;-)
Loads from

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.



Article: 77927
Subject: Re: LVDS through connectors
From: Georgi Beloev <gbH8SPAM@beloev.net>
Date: Thu, 20 Jan 2005 10:51:00 -0800
Links: << >>  << T >>  << A >>
Mark Smith wrote:
> Hi Georgi,
> 
> For Higher speeds, I would recommend the AMP Mictor connectors.
> 
> This document is a useful design guide:
> 
> http://www.latticesemi.com/lit/docs/technotes/tn1033.pdf
> Regards
> 
> Mark Smith
> Strategic Marketing
> Lattice Semiconductor

That's great, thanks!

-- Georgi



Article: 77928
Subject: Simulation error with ModelSim
From: clehobey@orange.fr (cedric)
Date: 20 Jan 2005 10:54:07 -0800
Links: << >>  << T >>  << A >>
hi,
I'm using ISE6.3.03i and ModelSim5.6.
I have a disign whitch work in simulation "Post Translate" and "Post Map".
But when I try to execute a simulation "Post Place And Route", resutl are strange.
The delay between rising egde and a new data change the result of my simulation.
Sometimes it's ok, and sometimes it's doesn't work.
I try several delay but I don't understand why!!

My constraint file :
clk = 160MHz
offset in = 6.25ns
offset out =6.25ns

thnaks for your answers.

Cédric

Article: 77929
Subject: Re: Simulation error with ModelSim
From: "vax, 9000" <vax9000@gmail.com>
Date: Thu, 20 Jan 2005 14:04:11 -0500
Links: << >>  << T >>  << A >>
cedric wrote:

> hi,
> I'm using ISE6.3.03i and ModelSim5.6.
> I have a disign whitch work in simulation "Post Translate" and "Post Map".
> But when I try to execute a simulation "Post Place And Route", resutl are
> strange. The delay between rising egde and a new data change the result of
> my simulation. Sometimes it's ok, and sometimes it's doesn't work.
> I try several delay but I don't understand why!!
> 
> My constraint file :
> clk = 160MHz
> offset in = 6.25ns
> offset out =6.25ns
It seems your clock speed is too fast for your design. Try to modify the
design, or choose a faster chip, or do both.

vax, 9000

> 
> thnaks for your answers.
> 
> Cédric


Article: 77930
Subject: Quartus Signal Tap problem
From: Al Clark <dsp@danvillesignal.com>
Date: Thu, 20 Jan 2005 19:08:58 GMT
Links: << >>  << T >>  << A >>
I am trying to use Signal Tap with a Cyclone. I have added nodes and set 
trigger conditions, data enable, compiled, etc and nothing ever triggers.

I noticed that three of my nodes have red trigger conditions. The rest of 
the line is Black. Could this be my problem? What does it mean and how do I 
work around it if it is?

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Article: 77931
Subject: Re: Hardened Logic and SEUs
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Thu, 20 Jan 2005 19:27:38 GMT
Links: << >>  << T >>  << A >>
Hi Austin,

So, in your opinion, would the FIT/Mb for a V2Pro (on 130nm) be higher or
lower than a V4 (on 90)? The area of a V2Pro DFF is larger, but the amount
of energy required to create an actual fault is higher too.

PS: feeling much better after (1) fixing just eentsily oxidized soldering
connection causing the boot failure and (2) getting my motorcycle permit.

Ben


> Roger,
> 
> The simple answer is that it is "they claim to be better".
> 
> That used to be the one big advantage an ASIC used to have over a FPGA:
> (note the past tense -- the fact that there are "so many fewer memory
> cells" means that "the upset rate is much less" - all else being equal).
> 
> The facts are less clear, at the latest technology nodes.
> 
> Since we, and the SRAM vendors do SEU testing (eg Cypress has a similar
> project to our Rosetta where they to simulation, beam testing, and
> atmospheric testing), we are the only two vendors that "know" what is
> happening (see our MAPLD presentation for the last few years).
> 
> But, look carefully at what Cypress is saying:  SRAM at 90 nm is ~ 3000
> FIT/Mb for atmospheric SEU's at sea level (which Cypress has improved to
> better than 1500 by design, doing things similar to what we are doing).
> 
> Our configuration latches in comparison are ~180 FIT/Mb at 90nm (latest
> extrapolation of all testing, with a margin of error of 1/2 to 2X --
> just need more time (or more errors).  Good position to be in.  Our
> promise is to get better with each technology, not worse.  And we are
> proving that to be true.
> 
> Well, a D FF in an ASIC (or hardened solution) is a pretty small animal
> at 90nm.  Our studies show its upset rate to be significantly higher
> than one would first suppose.  In fact, the 90nm standard cell D FF is
> the most sensitive element!  They are by, our calculations, 10X our CMOS
> configuration latch in terms of FIT/Mb.
> 
> If the FIT/Mb for 90 nm CMOS configuration latch is ~180, and it takes
> on average 10 tries to hit something 'critical' (a LUT, a piece of
> interconnect that matters - open/shorting something), then the mean time
> to fail is 18 FIT/Mb of config memory in our FPGAs.  Gee, 10X better.
> If the ASIC has even 1/10 the D FF and memory that the FPGA has, then
> they are equal in time to fail by atmospheric upsets....
> 
> By the way, the D FF in the CLB is 1 FIT/Mb, so it is so unlikely to be
> flipped, it is not even on the radar screen (can be ignored).
> 
> Now let us say that I use a XC4VLX60, and once I am done, I use a 2M
> gate ASIC (an actual customer story, one million gates + 1 million D
> FF's).  If we make a few reasonable calculations, I get ~500 years
> between functional failures in the FPGA (assuming you do not use our
> correction features, which would make this much much better (longer)),
> and ~500 years between functional failures for the 90nm ASIC.  So, given
> we are no better, no worse (on paper), and we can be better by using the
> FRAME_ECC, and other easy built in error correction techniques, we win
> in the SEU MTBF with the longest time to a failure category.
> 
> 
> Now, we know what we do, and we tell you.
> 
> For fun, go ask your vendors what their atmospheric MTBF is for soft
> errors (SEU, SEE, SER, SEL) for their hardened solution.
> 
> Many large companies are doing this (have done this).
> 
> They don't know.  Ask more closely, and do they know how to do Qcrit
> studies?  Can they follow JESD89?
> 
> Ask for the results.  We will talk about ours, just contact your FAE.
> 
> Are they hiding just how bad they really are?
> 
> Or, are they just afraid that they are really bad, and have no way to
> know (predict)?
> 
> Do they do beam testing? (we do)
> 
> Do they test for latch-up (which may destroy the chip)? (we do, and have
> to latch-up)
> 
> Do they do atmospheric experiments? (we do)
> 
> Do they promise to only get better from one generation to the next?  (we
> and Cypress both do)
> 
> So, we can not say they are "worse" but we can certainly say that they
> are not "better."
> 
> The truth is somewhere in between.
> 
> But I would choose the technology that knows what is going on, and has a
> means to predict the MTBF, and extend the MTBF hours by using simple
> built in features, if it is something that is needed.
> 
> Make a reliability spreadsheet for your system.  Set goals (hard and
> soft).  Then work with our FAEs to meet those goals.  It is called
> reliability engineering, and it may surprise you that the FPGA will win.
> 
> After all, being in satellites, autonomous aircraft, jet fighters,
> automobiles, and on Mars has taught us a lot about reliability
> engineering, and SEUs.
> 
> Go Mars Rovers!   One year and counting!
> 
> Austin
> 
> 
> Roger wrote:
>> Compared with a normal Stratix, is a HardCopy version immune to SEUs?
>> 
>> I'd have thought the possibility of a configuration error is reduced to
>> zero as the configuration SRAM cells have gone but an event in the logic
>> is still possible. Does anyone have any ideas (or figures maybe)?
>> 
>> TIA
>> 
>> Rog.
>> 
>>


Article: 77932
Subject: International Workshop on Applied Reconfigurable Computing ARC2005 - CALL FOR PARTICIPATION
From: jmpc@acm.org (Jo?o M. P. Cardoso)
Date: 20 Jan 2005 11:28:22 -0800
Links: << >>  << T >>  << A >>
CALL FOR PARTICIPATION
_____________________________________________________________________
International Workshop on Applied Reconfigurable Computing (ARC 2005)

URL: http://w3.ualg.pt/~jmcardo/arc2005
 
Algarve, Portugal, February 22-23, 2005
_____________________________________________________________________

To register, please fill in the form in
http://w3.ualg.pt/~jmcardo/arc2005/registration_arc2005.pdf and
sent it by FAX to: +351 21 3151244.

PROGRAM:
-------------------------------	
Tuesday 22 February 2005
-------------------------------		
9:30    Registration
10:00	Opening Session

10:15	Invited Speaker: Pedro Diniz
	University of Southern California / Information Sciences Institute,
CA, USA
	"Exploiting Data Reuse in Modern FPGAs: Opportunities and Challenges
for Compilers"

11:00	COFFE BREAK

11:15	SESSION A: (3 distinguished papers)
	APPLICATIONS I
	
11:15	"Optimized FPGA Implementation of a Multi Program PCR
Measurement System in DVB-T"
	Authors: C. Mannino, H. Rabah, C. Tanougast, Y. Berviller, M. Janiaut
and S. Weber
	Affiliation: Laboratoire d'Instrumentation Electronique de Nancy
(L.I.E.N.), U.H.P., Faculte des Sciences, France

11:40	"An FPGA Implementation of a Flexible Secure Elliptic Curve
Cryptography Processor"
	Authors: T. Kerins, W. P. Marnane, E. M. Popovici
	Affiliation: University College Cork, Ireland

12:05	"Network Intrusion Detection Systems on FPGAS with On-Chip
Network Interfaces"
	Authors: Chris Clark, Craig Ulmer
	Affiliation: Georgia Tech, Sandia National Labs, USA

12:30	LUNCH

14:00	SESSION B: (5 regular papers)
	DYNAMIC RECONFIGURATION AND ARCHITECTURES

14:00	"Function Replacement of Hard Real-Time Systems using Partial
Reconfiguration"
	Authors: Thomas Reinemann, Roland Kasper 
	Affiliation: IMAT, Otto-von-Guericke-University Magdeburg, Germany

14:20	"A Methodology for Hardware Tasks Scheduling Optimized in Time
for Partial and Dynamic Reconfiguration of FPGAS"
	Authors: Remy Eskinazi, Paulo Maciel, Manoel Eusebio de Lima, Paulo
Sergio Nascimento, Abel Guilhermino, Carlos Valderrama
	Affiliation: Federal University of Pernambuco, Brasil

14:40	"Towards a Runtime Reconfigurable Network-on-chip-based Network
Processor"
	Authors: Jürgen Foag, Roman Koch
	Affiliation: University of Luebeck, Germany

15:00	"Adopting the Small-World Network in Routing Structure of FPGA"
	Authors: Masahiro IIDA, Shinya ABE, Hisashi TSUKIASHI, Ryoji OGATA,
and Toshinori SUEYOSHI
	Affiliation: Kumamoto University, Japan

15:20	"Novel Switch-Block Architecture Using Reconfigurable Context
Memory for Multi-Context FPGAs"
	Authors: Wei Sheng CHONG, Masanori HARIYAMA, and Michitaka KAMEYAMA
	Affiliation: Tohoku University, Japan

15:40	COFFE BREAK

16:10	SESSION C: (5 regular papers)
	APPLICATIONS II

16:10	"Realisation of Real-Time Control Flow Oriented Automotive
Applications on a Soft-core Multiprocessor System based on Xilinx
Virtex II FPGAs"
	Authors: Katarina Paulsson, Michael Hübner, Hong Zou, and Jürgen
Becker
	Affiliation: Universitaet Karlsruhe (TH), Germany

16:30	"Optimise FPGA Implementation of an AES Algorithm for Embedded
Application"
	Authors: T. Liu, C. Tanougast, P. Brunet, Y. Berviller, H. Rabah, and
S. Weber
	Affiliation: Université Henri Poincaré Nancy I, France

16:50	"Efficient Decoding of Variable-Length Encoded Image Data on the
Nios II Soft-Core Processor"
	Authors: Peter Mårtensson, Jans Persson, Shang Xue, and Bengt Oelmann
	Affiliation: Mid Sweden University, Sweden

17:10	"An Efficient, Low Resource, Architecture for Backpropagation
Neural Networks"
	Authors: Pedro O. Domingos, and Horácio C. Neto
	Affiliation: INESC-ID, IST, Portugal

17:30	"FPGA Based Architecture for the Data Acquisition Electronics of
the Clear-PEM System"
	Authors: J. Varela, P. Bento, C. Leong, I. C. Teixeira, J. P.
Teixeira, J. Nobre, J. Rego, P.Lousã, P. Relvas, P. Rodrigues, and A.
Trindade
	Affiliation: LIP-Lisboa, Lisbon, Portugal; Universidade Técnica de
Lisboa, Instituto Superior Técnico, Lisbon, Portugal; INESC-ID,
Lisbon, Portugal; INOV, Lisbon, Portugal
		
-------------------------------	
Wednesday 23 February 2005		
-------------------------------	
8:45	SESSION D: (3 distinguished papers)
	ARCHITECTURES AND APPLICATIONS

8:45	"A RISC Architecture Extended by an Efficient Tightly Coupled
Reconfigurable Unit"
	Authors: N. Vassiliadis, N. Kavvadias, G. Theodoridis, and S.
Nikolaidis
	Affiliation: Section of Electronics and Computers, Department of
Physics, Aristotle University of Thessaloniki,54124 Thessaloniki,
Greece

9:10	"A Dynamic Optically Reconfigurable Gate Array using Dynamic
Method"
	Authors: Minoru Watanabe, and Fuminori Kobayashi
	Affiliation: Kyushu Institute of Technology in Japan, Japan

9:35	"A Fault Tolerant Gesture Recognition System for Mobile Robot"
	Authors: Vanderlei Bonato, Márcio M. Fernandes, and Eduardo Marques
	Affiliation: Institute of Mathematics and Computing Sciences,
University of São Paulo, Brasil

10:05	COFFE BREAK

10:35	SESSION E: (5 regular papers)
	TOOLS,TECHNIQUES, AND METHODOLOGIES
	
10:35	"A Methodology for Parameterized Algorithm Design to Support
Flexible FPGA Based System Design"
	Authors: Aparna Nagargadde, Sridhar Gangadharpalli, and Sridhar V. 
	Affiliation: Applied Research Group, Satyam Computer Services
Limited; Entrepreneurship Centre, Indian Institute of Science Campus,
Bangalore

10:55	"Pipelining Sequences of Loops: A First Example"
	Authors: Rui Rodrigues, and João M. P. Cardoso
	Affiliation: University of Algarve, Portugal

11:15	"Open Architecture Hierarchical Placement for FPGA Datapath
Designs"
	Authors: Dong Kwan Kim, Cameron Patterson, and Peter Athanas
	Affiliation: Virginia Polytechnic Institute and State University, USA

11:35	"Optimizing Area on the Generation of Specific Circuits in FPGAs
for SIMD Applications"
	Authors: Germán León, José M. Claver, and  Germán Fabregat
	Affiliation: University Jaume I, Spain

11:55	"A Test Infrastructure for Compilers Targeting FPGAS"
	Authors: Rui Rodrigues, and João M. P. Cardoso
	Affiliation: University of Algarve, Portugal

12:10	Closing Session

Article: 77933
Subject: Copying/Reverse Engineering PAL
From: "logjam" <grant@cmosxray.com>
Date: 20 Jan 2005 11:29:07 -0800
Links: << >>  << T >>  << A >>
I am trying reproduce a Macintosh 128k using CMOS parts.  It has some
16R4, 16R8, and 16L8 PALs.  If you could give me any advice about how I
should "learn" the logic in these that would be GREAT!  Maybe a method
of bit twiddling all the inputs to see what happens?  The 16L8 should
be simple, but that is only one of the 6.  I have signal names and a
schematic, but the internal design of the 'R' chips scares me.  :)

Is there any programmer that can use a brute force technique of trying
all possible logic combinations?

I want to do this to learn another aspect of old computers, and because
I'd like to replace all the chips with new CMOS and see if I can't get
overclock the thing.  ;)


Thanks for your time,
Grant


Article: 77934
Subject: Re: LVDS through connectors
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Thu, 20 Jan 2005 19:47:46 GMT
Links: << >>  << T >>  << A >>
Hi Georgi,

> Any thoughs about vias on the signal traces?

Avoid them as much as possible (they're major jitter sources), make them
blind vias or counter-bore them to make them as short as possible
(cheaper), and make sure that the signal path goes from the top end of the
metal to the bottom (or the other way around). Leftover metal does nasty
things to the signal.

See 

http://www.tycoelectronics.com/products/simulation/files/papers/dc00brdh.pdf

for some great information on this.

Ok, you're not running at 5Gbps, but it never hurts following these rules.

Best regards,


Ben


Article: 77935
Subject: Re: Asic prototyping in Fpga - prototyping the gates.
From: "gretzteam" <david.lamb@gmail.com>
Date: 20 Jan 2005 12:00:20 -0800
Links: << >>  << T >>  << A >>
Hi,
thanks for the reply.
Its good news to know that it is possible to do. However, I'm not quite
sure I understand what you are saying. Could you please give more
details of the things to do? Have you ever done it? How good is
performance?

Thanks,
David


mk wrote:
> On 20 Jan 2005 09:11:59 -0800, "gretzteam" <david.lamb@gmail.com>
> wrote:
>
> >Hi,
> >We are currently using virtexIIpro and virtex4 fpga to prototype a
dsp
> >processor. All the code is synthesizable verilog and we are using
> >Xilinx ISE to do synthesis and place and route. Everything works
fine
> >and the processor runs at full speed (50Mhz). However, this is only
> >good for functionnal verification on the bench. The ASIC flow and
the
> >FPGA flow are very different so the actual gates in the FPGA are
> >different than what will be on the ASIC. For example, we can't use
the
> >FPGA to verify the test vectors and scan chains that the test
engineer
> >is working on.
> >
> >Is it possible to prototype the EXACT same gates that will be in the
> >ASIC? We use Synopsys Design Compiler to generate the ASIC gates.
> >Basically is there a way to take the gates generated by Design
> >Compiler, and map them in the FPGA? We don't really care if this
runs
> >slower, but it would allow the test engineer to start working on all
> >the test vectors before we receive silicon.
> >
> >Thank you very much,
> >David
>
> Yes of course. What you need to do is to take the standard cell
> library file(s) which define the behavior of individual gates and add
> it your gate level netlist during synthesis. All combinational gates
> will have their behaviour described in a synthesizable way in the
> library. The only case where this will not work are the latches and
> flip-flops as they are most probably defined as udps which are not
> synthesizable but they are relatively easy to code in behavioral rtl.
> the same situation may exists for muxes but that's doable too. but of
> course you have to understand that even these gates will be mapped to
> the luts on the fpga.


Article: 77936
Subject: Re: Problem with Signal Tap II Logic Analyzer in Altera Quartus II 4.1 and Microtronix Stratix development board
From: "Subroto Datta" <sdatta@altera.com>
Date: 20 Jan 2005 12:15:33 -0800
Links: << >>  << T >>  << A >>
Hi Sebastian,
The first two things to try in this this situation are:

1) Ensure all unused pins are "Inputs tri-stated"
2) Use a USBB instead of BB

If these do not work, let me know and I will have a support person
contact you for more details.

Hope this helps,
Subroto Datta
Altera Corp.

Sebastian Schmidt wrote:
> Hi.
>
> A colleague and me are having problems getting the SignalTap II Logic

> Analyzer from Quartus II running on our Stratix device.
> We compiled a NIOS example-design and programmed it to the device. We
know
> the example is working because we loaded a little C-program to the
NIOS
> which resulted in correct output. We also tried to use Signaltap with
a
> self-created simple design but this also didn't work.
> We tried to use the SignalTap II Logic Analyzer in two ways:
> 1) We opened the Signaltap II Logic Analyzer from the Tools menu in
> Quartus. There we added the nodes we tried to analyze. We enabled
> SignalTap II Logic Analyzer in the project's settings and chose the
> created stp-file there. We followed the instructions we got from the

> program which told us to compile the design and then to program the
> device. After programming the device, SignalTap still told us to
program
> the device. In the documention it says that "Ready to acquire" should
be
> the next message but we still get "Program the device to continue".
When
> we try to ignore the message and acquire data anyway we get a JTAG
> communication error.
> 2) The second way was to create an instance of a SignalTap II Logic
> Analyzer using the MegaWizard Plug-In Manager and added it to the
design.
> We connected the inputs (clock, data, trigger), then we created a
stp-file
> using the menu item as described in the documentation. This way we
> encountered the same problems as before.
>
> We don't know what we are doing wrong, can anybody help us getting
the  
> SignalTap II Logic Analyzer running?
> 
> Thanks.


Article: 77937
Subject: Xilinx Sum in VHDL
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 20 Jan 2005 12:37:50 -0800
Links: << >>  << T >>  << A >>
Hello FPGA group,

I have to create this sum
A+2B+C
where A, B, and C are 8 bit std_logic_vector
as part of a Sobel function.

What is the best way of doing this?

I have been able to get correct results
with the following:

 signal  sum : std_logic_vector(9 downto 0);
 begin
 sum <= ("00"&in1) + ('0'&in2&'0') + ("00"&in3) ;

However I find this code looks a bit sticky and I
wonder if it may be synthesizing 10 bit adders to
do 8 bit work.  The Map report says that I am
using 15 LUTs and 9 slices.

Spartan 3, and most of the other Xilinx parts, have an
ADD8 macro, according to the library guide, but I
couldn't find how to instantiatie this as a component.
Are macros components?

Thanks for your consideration,

Brad Smallridge
brad at www.aivision.com





Article: 77938
Subject: Re: C programmer, what does this syntax mean?
From: Mark McDougall <msmcdoug@no.spam.iinet>
Date: Fri, 21 Jan 2005 07:53:14 +1100
Links: << >>  << T >>  << A >>
Fat Cat wrote:

> I am a bit confused. I have never seen such syntax even though I read a
> lot of C++ codes.

I am a bit confused. I don't know how you could've read more than 1 or 2 
examples of C++ code without coming across everything in your example?!?

Regards,

-- 
|              Mark McDougall                | "Electrical Engineers do it
|         <http://to be announced>           |   with less resistance!"

Article: 77939
Subject: Re: Comparison of LEON2, Microblaze and Openrisc processors
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 21 Jan 2005 09:54:33 +1300
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> I have an unpublished success-story about using MicroBlaze in Commercial Product using XC2S100 with no external memory. Thats I think the smallest FPGA where Microblaze (at least Xilinx version!) can be used. The open- source MicroBlaze used in simple controller fashion could possible be useable in S50 too. Or small smallest Cyclone :)

Have you tried the OpenSource MicroBlz, from serial FLASH memory ?
With the 50MHz SPI models, you peak at ~6MBaud streaming bandwidth,
(which of course drops on jumps). That's enough for many apps,
and with a little cache using one block ram, inner loops could fit
on-chip.

-jg


Article: 77940
Subject: Re: Xilinx Sum in VHDL
From: Mark McDougall <msmcdoug@no.spam.iinet>
Date: Fri, 21 Jan 2005 07:58:18 +1100
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:

> However I find this code looks a bit sticky and I
> wonder if it may be synthesizing 10 bit adders to
> do 8 bit work.  The Map report says that I am
> using 15 LUTs and 9 slices.

Umm, you're *not* 'doing 8 bit work'?!?

-- 
|              Mark McDougall                | "Electrical Engineers do it
|         <http://to be announced>           |   with less resistance!"

Article: 77941
Subject: Re: Asic prototyping in Fpga - prototyping the gates.
From: "MikeJ" <support@{nospam}fpgaarcade.com>
Date: Thu, 20 Jan 2005 22:12:38 -0000
Links: << >>  << T >>  << A >>
In a similar way to when you use the Xilinx tools to take a placed and
routed design and produce a VHDL (for example) file which contains a whole
load of simple gates. To simulate this, you either use their library which
includes timing information, or a simple functional description of the
gates. This allows you to test the final design rather than just simulating
the source files.

You should be able to take the output of Design Compiler, and write a simple
functional (and synthesizable) cell library. You could then push all this
through the xilinx tool set and produce a routed design. Of course, the
Xilinx devices use luts as the logic primitive, but you would at least be
starting from the Asic gate description.

/Mike


> Hi,
> thanks for the reply.
> Its good news to know that it is possible to do. However, I'm not quite
> sure I understand what you are saying. Could you please give more
> details of the things to do? Have you ever done it? How good is
> performance?
>
> Thanks,
> David
>
>
> mk wrote:
> > On 20 Jan 2005 09:11:59 -0800, "gretzteam" <david.lamb@gmail.com>
> > wrote:
> >
> > >Hi,
> > >We are currently using virtexIIpro and virtex4 fpga to prototype a
> dsp
> > >processor. All the code is synthesizable verilog and we are using
> > >Xilinx ISE to do synthesis and place and route. Everything works
> fine
> > >and the processor runs at full speed (50Mhz). However, this is only
> > >good for functionnal verification on the bench. The ASIC flow and
> the
> > >FPGA flow are very different so the actual gates in the FPGA are
> > >different than what will be on the ASIC. For example, we can't use
> the
> > >FPGA to verify the test vectors and scan chains that the test
> engineer
> > >is working on.
> > >
> > >Is it possible to prototype the EXACT same gates that will be in the
> > >ASIC? We use Synopsys Design Compiler to generate the ASIC gates.
> > >Basically is there a way to take the gates generated by Design
> > >Compiler, and map them in the FPGA? We don't really care if this
> runs
> > >slower, but it would allow the test engineer to start working on all
> > >the test vectors before we receive silicon.
> > >
> > >Thank you very much,
> > >David
> >
> > Yes of course. What you need to do is to take the standard cell
> > library file(s) which define the behavior of individual gates and add
> > it your gate level netlist during synthesis. All combinational gates
> > will have their behaviour described in a synthesizable way in the
> > library. The only case where this will not work are the latches and
> > flip-flops as they are most probably defined as udps which are not
> > synthesizable but they are relatively easy to code in behavioral rtl.
> > the same situation may exists for muxes but that's doable too. but of
> > course you have to understand that even these gates will be mapped to
> > the luts on the fpga.
>



Article: 77942
Subject: Re: Copying/Reverse Engineering PAL
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Thu, 20 Jan 2005 22:47:44 GMT
Links: << >>  << T >>  << A >>
"logjam" <grant@cmosxray.com> wrote in message 
news:1106249347.233017.138400@f14g2000cwb.googlegroups.com...
>I am trying reproduce a Macintosh 128k using CMOS parts.  It has some
> 16R4, 16R8, and 16L8 PALs.  If you could give me any advice about how I
> should "learn" the logic in these that would be GREAT!  Maybe a method
> of bit twiddling all the inputs to see what happens?  The 16L8 should
> be simple, but that is only one of the 6.  I have signal names and a
> schematic, but the internal design of the 'R' chips scares me.  :)

Hmm. I think that noting the connections to the CPU will provide some useful 
clues. Is the circuit diagram online?

I have a copy of the 3rd edition of "The Programmable Logic Handbook" by 
MMI.
Antique technology but since it was from the dawn of PLD days it has very 
useful code examples. Like connecting the 68K to Zilog peripheral chips. I 
can scan the notes that you want.

MikeJ of FPGA arcade is resurrecting the Atari ST, so some fundamentals may 
match the Mac.

Cheers, K. 



Article: 77943
Subject: How does a SDRAM controller work?
From: jeffsen <xjf77@yahoo.com>
Date: Thu, 20 Jan 2005 15:06:52 -0800
Links: << >>  << T >>  << A >>
Dear all, Normally SDRAM needs tens of MS to refresh bank of memory,while what happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regards

Article: 77944
Subject: Re: Passing OPB signals through submodule
From: "jralston" <jralston@calpoly.edu>
Date: Thu, 20 Jan 2005 18:23:34 -0500
Links: << >>  << T >>  << A >>
Thanks for the advice.  I was able to get it working, turns out my problem
was a timing issue on the IP2Bus_Ack line.  

For the interrupts I figured out that I could not just set the global
interrupt handler in the Microblaze S/W settings in EDK, but had to do it
explicitly by adding the line:
microblaze_register_handler(int_handle, (void*)0);
to my setup routine.


Article: 77945
Subject: Re: Xilinx Sum in VHDL
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 20 Jan 2005 15:24:46 -0800
Links: << >>  << T >>  << A >>

> Umm, you're *not* 'doing 8 bit work'?!?

Hello Mark,

OK, it seems to me that the best solution is
one eight bit adder with a carry, going into
a nine bit adder (maybe not if I don't care about
the lower bits) with a carry, giving me a 10 bit sum.

My question is (was), does this VHDL give me
10 bit adders throughout, instead of an optimised
solution, on a Xilinx XST platform?

And is this, overall, the best way of doing a sum
like this?

Mark, is that clearer?

Brad




 



Article: 77946
Subject: Re: Hardened Logic and SEUs
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 20 Jan 2005 15:28:27 -0800
Links: << >>  << T >>  << A >>
Ben,

Well, based on the numbers I gave, V2P has a higher FIT/Mb rate than V4, 
but generally speaking the V2P chip folks use is smaller (less memory 
cells, less logic) than the V4 chips.

So, at one time the sweet spot part for Virtex was a XCV300.

Then for the Virtex E it went up to a XCV600E.

With Virtex II, it was  2V1000.

In Virtex 2 Pro, is is the 2VP30.

In Virtex 4, we suspect it will be the XC4VLX60.  At least that is what 
a lot of folks are getting shipped as samples right now.  Although the 
LX25 is pretty popular as well.  Not to mention their is a huge volume 
application for FX12's that might outstrip all of the 
others....predicting the high runner a-priori is just gambling.

So, if customers would just stop using more logic, we would be getting 
'better' in each device (of the same size) since Virtex II.

But, customers will pack more stuff in (for less money), so the 
FIT/family gets slightly worse, even though the FIT/Mb is better, just 
because larger parts are being compared to smaller parts.  Hence the 
reason why we have to work so hard to get better, so we don't get worse 
overall.

That is the reason why we added the FRAME_ECC to correct errors in V4: 
parts are growing faster than we are decreasing the FIT/Mb rate 
(although we are doing that, too).  So on a system basis, we still must 
get better.

Austin


Ben Twijnstra wrote:
> Hi Austin,
> 
> So, in your opinion, would the FIT/Mb for a V2Pro (on 130nm) be higher or
> lower than a V4 (on 90)? The area of a V2Pro DFF is larger, but the amount
> of energy required to create an actual fault is higher too.
> 
> PS: feeling much better after (1) fixing just eentsily oxidized soldering
> connection causing the boot failure and (2) getting my motorcycle permit.
> 
> Ben
> 
> 
> 
>>Roger,
>>
>>The simple answer is that it is "they claim to be better".
>>
>>That used to be the one big advantage an ASIC used to have over a FPGA:
>>(note the past tense -- the fact that there are "so many fewer memory
>>cells" means that "the upset rate is much less" - all else being equal).
>>
>>The facts are less clear, at the latest technology nodes.
>>
>>Since we, and the SRAM vendors do SEU testing (eg Cypress has a similar
>>project to our Rosetta where they to simulation, beam testing, and
>>atmospheric testing), we are the only two vendors that "know" what is
>>happening (see our MAPLD presentation for the last few years).
>>
>>But, look carefully at what Cypress is saying:  SRAM at 90 nm is ~ 3000
>>FIT/Mb for atmospheric SEU's at sea level (which Cypress has improved to
>>better than 1500 by design, doing things similar to what we are doing).
>>
>>Our configuration latches in comparison are ~180 FIT/Mb at 90nm (latest
>>extrapolation of all testing, with a margin of error of 1/2 to 2X --
>>just need more time (or more errors).  Good position to be in.  Our
>>promise is to get better with each technology, not worse.  And we are
>>proving that to be true.
>>
>>Well, a D FF in an ASIC (or hardened solution) is a pretty small animal
>>at 90nm.  Our studies show its upset rate to be significantly higher
>>than one would first suppose.  In fact, the 90nm standard cell D FF is
>>the most sensitive element!  They are by, our calculations, 10X our CMOS
>>configuration latch in terms of FIT/Mb.
>>
>>If the FIT/Mb for 90 nm CMOS configuration latch is ~180, and it takes
>>on average 10 tries to hit something 'critical' (a LUT, a piece of
>>interconnect that matters - open/shorting something), then the mean time
>>to fail is 18 FIT/Mb of config memory in our FPGAs.  Gee, 10X better.
>>If the ASIC has even 1/10 the D FF and memory that the FPGA has, then
>>they are equal in time to fail by atmospheric upsets....
>>
>>By the way, the D FF in the CLB is 1 FIT/Mb, so it is so unlikely to be
>>flipped, it is not even on the radar screen (can be ignored).
>>
>>Now let us say that I use a XC4VLX60, and once I am done, I use a 2M
>>gate ASIC (an actual customer story, one million gates + 1 million D
>>FF's).  If we make a few reasonable calculations, I get ~500 years
>>between functional failures in the FPGA (assuming you do not use our
>>correction features, which would make this much much better (longer)),
>>and ~500 years between functional failures for the 90nm ASIC.  So, given
>>we are no better, no worse (on paper), and we can be better by using the
>>FRAME_ECC, and other easy built in error correction techniques, we win
>>in the SEU MTBF with the longest time to a failure category.
>>
>>
>>Now, we know what we do, and we tell you.
>>
>>For fun, go ask your vendors what their atmospheric MTBF is for soft
>>errors (SEU, SEE, SER, SEL) for their hardened solution.
>>
>>Many large companies are doing this (have done this).
>>
>>They don't know.  Ask more closely, and do they know how to do Qcrit
>>studies?  Can they follow JESD89?
>>
>>Ask for the results.  We will talk about ours, just contact your FAE.
>>
>>Are they hiding just how bad they really are?
>>
>>Or, are they just afraid that they are really bad, and have no way to
>>know (predict)?
>>
>>Do they do beam testing? (we do)
>>
>>Do they test for latch-up (which may destroy the chip)? (we do, and have
>>to latch-up)
>>
>>Do they do atmospheric experiments? (we do)
>>
>>Do they promise to only get better from one generation to the next?  (we
>>and Cypress both do)
>>
>>So, we can not say they are "worse" but we can certainly say that they
>>are not "better."
>>
>>The truth is somewhere in between.
>>
>>But I would choose the technology that knows what is going on, and has a
>>means to predict the MTBF, and extend the MTBF hours by using simple
>>built in features, if it is something that is needed.
>>
>>Make a reliability spreadsheet for your system.  Set goals (hard and
>>soft).  Then work with our FAEs to meet those goals.  It is called
>>reliability engineering, and it may surprise you that the FPGA will win.
>>
>>After all, being in satellites, autonomous aircraft, jet fighters,
>>automobiles, and on Mars has taught us a lot about reliability
>>engineering, and SEUs.
>>
>>Go Mars Rovers!   One year and counting!
>>
>>Austin
>>
>>
>>Roger wrote:
>>
>>>Compared with a normal Stratix, is a HardCopy version immune to SEUs?
>>>
>>>I'd have thought the possibility of a configuration error is reduced to
>>>zero as the configuration SRAM cells have gone but an event in the logic
>>>is still possible. Does anyone have any ideas (or figures maybe)?
>>>
>>>TIA
>>>
>>>Rog.
>>>
>>>
> 
> 

Article: 77947
Subject: Re: Xilinx Sum in VHDL
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Jan 2005 16:00:33 -0800
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:


> OK, it seems to me that the best solution is
> one eight bit adder with a carry, going into
> a nine bit adder (maybe not if I don't care about
> the lower bits) with a carry, giving me a 10 bit sum.

> My question is (was), does this VHDL give me
> 10 bit adders throughout, instead of an optimised
> solution, on a Xilinx XST platform?

 From the software I know, it likely will generate that, but
during place and route any redundant gates will be removed.

The result, then, should be just what you say, unless the
addition is done in a different order.

Systems I know about will remove FF's with constant inputs,
combine registers with the same inputs, remove gates where
all the inputs, or all but one are constant, eliminate
inverters by inverting the output of the preceding device,
and probably more.  Usually there are messages telling what
it is doing.

-- glen


Article: 77948
Subject: Re: How does a SDRAM controller work?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 21 Jan 2005 00:06:07 GMT
Links: << >>  << T >>  << A >>
On Thu, 20 Jan 2005 15:06:52 -0800, jeffsen <xjf77@yahoo.com> wrote:

>Dear all, Normally SDRAM needs tens of MS to refresh bank of memory,while what happens when I happened to visit this memory address,either read or write. Dose the SDRAM controller(say,IP core from Xilinx) makes this read/write operation waiting for this refresh period and execute read/write command afterwards(That's unacceptable in term of time or speed for this read/write operation!)? Or it handles such condition in another way? Thanks for your information. regards

You misunderstand. 
Each memory row needs to be refreshed every <x> milliseconds, but the refresh cycle itself only
takes a few clock cycles. 

I'd recommend reading one of the Micron SDRAM datasheets as they have pretty good explanations of
SDRAM.


Article: 77949
Subject: Re: Xilinx Sum in VHDL
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Jan 2005 00:12:59 GMT
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10v0fe7igutmt55@corp.supernews.com...
[ snip ]
> OK, it seems to me that the best solution is
> one eight bit adder with a carry, going into
> a nine bit adder (maybe not if I don't care about
> the lower bits) with a carry, giving me a 10 bit sum.
>
> My question is (was), does this VHDL give me
> 10 bit adders throughout, instead of an optimised
> solution, on a Xilinx XST platform?
>
> And is this, overall, the best way of doing a sum
> like this?
[ snip ]

Since your synthesis shows 15 LUTs used, I expect that the sum is the
cascade of 2 9-bit adders.  Consider that A+C is a 9 bit value but the LSbit
is added to zero so it can pass straight through without going to another
adder.  The second adder takes the top 8 bits of the 9-bit A+C result and
adds it to the 8-bit shifted B value.  I would have expected 16 LUTs in the
two 8-bit adders (with "free" carry-outs) but the synthesizer might have
combined something for the LSbits saving you a LUT.

I use Synplify for my synthesis and go to the HDL Analyzer to check the
synthesizer's implementation when I have efficiency concerns.  I get full
visibility into the technology level implementation, no questions.

You're probably doing great on efficiency.





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