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 32975

Article: 32975
Subject: Re: Design entry
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Fri, 13 Jul 2001 13:36:16 -0600
Links: << >>  << T >>  << A >>
John_H wrote:
> 
> HDL, not schematics, yes!  yes!
> Verilog and VHDL are both appropriate to the task.
> It's a little like the age old question (probably still valid in your corner of
> this world:  "Coke or Pepsi?"
> If you have tools for and/or experienced designers that use one HDL, it's a
> great way to go.

I use schematics and drink "No-Name Cola".
One advantage schematics may be ( with a good
macro library ) for the large amount of small TTL projects 
that are around.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.

Article: 32976
Subject: Re: Xilinx BRAM failures
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 13 Jul 2001 22:07:01 +0200
Links: << >>  << T >>  << A >>
Achlys4now@yahoo.com (Achlys) writes:

> These are repeatable, hard failures that are temperature insensitive.
> Replacing the IC usually fixes it. The design(s) is now fairly mature
> and is being functionally enhanced. Replacing the suspect block ram
> with a different resource internally can fix the problem. Same design,
> new placement with both routes meeting the timing constraints. Yikes!
> Not good for field upgrades.

I've had this kind of problem with FPGAs. A design worked in some
devices, and it didn't in other. Re-P&R solved the problem, and the it
came back after the next alteration of the design. I can't remember if
temperature changed it, but I think not. The failure/success was very
deterministic.

The error? Having an unsynchronized signal going into a
statemachine. One part of the statemachine went one way, the other
part did not. It took we a while to figure that one out. It was
strange to see what can happen if you aren't careful.

I have no idea if this is applicable to your case, it just sounded so
familiar.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 32977
Subject: Re: Design entry
From: John_H <johnhandwork@mail.com>
Date: Fri, 13 Jul 2001 20:45:15 GMT
Links: << >>  << T >>  << A >>
HDL, not schematics, yes!  yes!
Verilog and VHDL are both appropriate to the task.
It's a little like the age old question (probably still valid in your corner of
this world:  "Coke or Pepsi?"
If you have tools for and/or experienced designers that use one HDL, it's a
great way to go.

You'll also find a new newsgroup to visit - comp.lang.verilog or
comp.lang.vhdl.

If you get in the habit of using HDL early on, you'll be in great shape for
some interesting design challenges.

- John


Noddy wrote:

> Hi,
>
> As you've guessed from recent posts, I'm very new to using FPGAs (couple of
> months). I've been spending my time implementing schematic design entries
> (using Foundation ISE). This brings me to my question? Should I rather be
> attempting to implement my designs in VHDL instead? My experience with VHDL
> is the Designer's Guide to VHDL!
>
> Any suggestions?
>
> Adrian


Article: 32978
Subject: Re: Design entry
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 13 Jul 2001 23:00:23 +0200
Links: << >>  << T >>  << A >>
John_H <johnhandwork@mail.com> writes:

> Verilog and VHDL are both appropriate to the task.

> It's a little like the age old question (probably still valid in
> your corner of this world: "Coke or Pepsi?"

Actually, it's more like "Coke or a beer?". One is common in the US, the other
you can have more fun with...

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 32979
Subject: Re: Design entry
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Jul 2001 21:20:02 GMT
Links: << >>  << T >>  << A >>
My feeling on this is HDLs give you more flexibility when it comes to
parameterizing your designs, and much better testbenches.  Also, an HDL doesn't
require a proprietary view to browse the design (although it may need a specific
version of the synthesizer to generate exactly what you intended).  Other than
these points, I find that properly done schematics or HDL are appropriate.  For
either, proper use of hierarchy plays a much bigger role in reusability,
readability, documentation, and troubleshooting than does the choice of a design
entry tool.  I actually like to discourage newbies to FPGAs and/or digital design
using HDLs, as the abstraction tends to hide poor design practice, as well as the
obvious architectural tailoring you can easily do in the design if you are close
to the underlying chip architecture.  HDLs make it too easy to design something
that is very difficult/expensive in hardware and many times the designer doesn't
even realize it.

VHDL is a a powerful tool, but it does not make a lousy design magically good and
since it tends to hide the details it may not be obvious the design is lousy.



Magnus Homann wrote:

> John_H ?johnhandwork@mail.com? writes:
>
> ? Verilog and VHDL are both appropriate to the task.
>
> ? It's a little like the age old question (probably still valid in
> ? your corner of this world: "Coke or Pepsi?"
>
> Actually, it's more like "Coke or a beer?". One is common in the US, the other
> you can have more fun with...
>
> Homann
> --
> Magnus Homann, M.Sc. CS ? E
> d0asta@dtek.chalmers.se

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32980
Subject: Re: How do I distribute cores?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 13 Jul 2001 21:27:38 GMT
Links: << >>  << T >>  << A >>
There are ways around distributing source.  For simulation you can either
include a behavioral model that is bit and clock cycle true (this is what we do
for our HDTV cores), or you can distribute compiled libraries for the major
simulators (for example, modelsim distributes the ieee libraries compiled....no
source) so that the design can be simulated with the actual design without
divulging the source.  Yes, virtually enything engineered by man can also be
reverse engineered, but you can take steps to make it require more effort.  In
the license agreement, we put a clause prohibiting any decompiling of the
machine files...of course the only effect is to give your lawyer a leg to stand
on if you catch someone.  With adequate documentation and suitable simulation
models or compiled libraries, an end user does not have to have visibility into
the source.  Look at the xilinx coregen library for example.  Very few of those
have any source provided.

Steve Casselman wrote:

> ? The same problem exists for distributing source code for software.
> ? Non-disclosure agreements, licensing and sueing, are the only things I can
> ? think ok.
>
> You have the same problem with any program. You can disassemble anything and
> reverse engineer anything. You might consider a Open Source type of thing
> where you just sell the code and trust no one will distribute it (with
> licensing agreements). I think most of the people who buy IP really need to
> have source to simulate it right and what not.  Just charge for it.
>
> Steve

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com



Article: 32981
Subject: Re: Xilinx BRAM failures
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 14 Jul 2001 00:03:38 +0100
Links: << >>  << T >>  << A >>


Achlys wrote:

> Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3B4DFEB5.3EB92611@flukenetworks.com>...
> > Achlys wrote:
> > >
> > > Is anyone experiencing block ram failures in Xilinx Virtex-E devices?
> > > We've seen a condition where different bit files will cause hard
> > > failures on a small percentage of the parts.
> >  . . .
> > > Re-synthesising the design helps sometimes but not always.
> > > Working boards will fail with new bit files. We've seen the failure on
> > > multiple parts and on multiple designs.
> >
> >
> >
> > Sounds like a race condition somewhere.
> > Did static timing run ok?
> >
> >
> >
> Hi Mike,
>
> Static timing is ok - and we have updated timing files (Service pack
> 8). As you probably know Xilinx had incorrect timing files. When we
> first started this project we had the intermittent type problems
> caused by race conditions. This was from DesignManager reporting OK
> timings which were actually 1-2ns over.
>
> These are repeatable, hard failures that are temperature insensitive.
> Replacing the IC usually fixes it. The design(s) is now fairly mature
> and is being functionally enhanced. Replacing the suspect block ram
> with a different resource internally can fix the problem. Same design,
> new placement with both routes meeting the timing constraints. Yikes!
> Not good for field upgrades.
>
> Sound familiar to anyone?
>
> Thanks
>
> >
> >   --Mike Treseler

Have you tried a post-route simulation with the clock speed(s) set to the timing analysis values ?
I have had one case, quite a long time ago, where the timing analysis said the design was o.k. but it failed
simulation. Looking further I traced this down to a change in the default value of some of the timing path control
flags from enabled to disabled - notably "reg_sr_clk" & "ram_d_o".

Note also that I regularly over-clock Virtex-E designs by between 20-30% with no problems so there is a fair bit
of margin in worst case timing.




Article: 32982
Subject: Re: Design entry
From: arast@inficom.com (Alex Rast)
Date: Fri, 13 Jul 2001 23:45:32 GMT
Links: << >>  << T >>  << A >>
In article <994923743.528258@turtle.ru.ac.za>, "Noddy" <g9731642@campus.ru.ac.za> wrote:
>Hi,
>
>As you've guessed from recent posts, I'm very new to using FPGAs (couple of
>months). I've been spending my time implementing schematic design entries
>(using Foundation ISE). This brings me to my question? Should I rather be
>attempting to implement my designs in VHDL instead? My experience with VHDL
>is the Designer's Guide to VHDL!
>

Most people, I'm sure, are going to tell you to use HDL's. I'm going to 
register a different opinion and say that to make a blanket statement, that 
such-and-such a tool is the way to go, limits your options and may not be the 
best way to go. I think it's a case of a different tool for a different type 
of job. It really depends what it is that you're trying to do that will 
determine what's the best tool. Since you're using Xilinx (as the Foundation 
software indicates), I'll go over the plusses and minuses of each.

You have 4 basic options: HDL, state machine, schematic, or FPGA editor. These 
roughly correspond to decreasing levels of abstraction.

HDL's excel in complex but well-defined designs, where you know exactly what 
it is that your logic must do, but what it needs to do is complex and 
involved. If you think in an "algorithmic" or software-like way, in other 
words, you view your logic as "code" that you need to execute, HDL's will be 
the tool you'll be most comfortable with. They let you describe your logic in 
a source-code-like manner, and they'll let you do some very involved stuff. 
The tools for HDL have extraordinary sophistication, with plenty of 
verification and simulation options, lots of different flavors of synthesis 
entry, and usually a great many options in the program itself. HDL's are also, 
oddly, very good for really quick, simple logic functions that you don't feel 
like taking the time to figure out how the hardware would have to be for them.

The downside of HDL's is that the abstraction isolates you very much from the 
details of what's going on in the hardware. Typically you don't have ultimate 
control over how the software will actually implement your design on the chip. 
Furthermore, although the range of functions you can implement is amazing, 
abstracting the functionality still means that at a certain level you limit 
your design to the kinds of logic functions and blocks that the designers of 
the software envisioned. In other words, HDL's aren't your best bet if you're 
looking to tweak the last inch of performance, or utilization from your FPGA, 
or if you're doing something so bizarre that it falls outside the boundaries 
of what the software writers assumed you might be doing. Finally, there's the 
risk, with such a high degree of isolation, that you may try to implement 
something either too complex or at least very expensive to implement on the 
hardware. This could either hamper your design or be an outright barrier to 
success. So HDL's are things you should use with care, mostly to design 
relatively mature logic functions.

State machine entry works well when your design is simple and has a linear 
flow. If you think in a sequential way, seeing your logic as a series of 
states that the system steps through, the FSM entry method will seem logical 
to you. You could perhaps get quite complex, depending on how big of a state 
machine you care to visualize. It's great for simple controllers, especially 
ones with feedback where a state-machine description is fitting and natural. 
Even relatively complex, closed-loop control systems are good with this kind 
of system. Nevertheless, it really comes into its own with semi-simple 
functions, ones that may be more clear with a visual representation, and where 
the source-code representation of an HDL might make it more opaque what's 
actually going on.

The tools, OTOH, aren't very sophisticated or thought through. Third-party 
support is rare at best, and you'll probably end up using Xilinx' simulation 
and verification tools. Furthermore, at some point the design may become very 
difficult to follow, when you have hundreds of states, and since this method 
still isolates you from the underlying logic, there's no benefit to displaying 
a complex design in this way. In many respects, FSM design opens up the same 
weaknesses as HDLs, although admittedly it's pretty clear if you've got a 
state machine description that you're not doing anything bleeding-edge, so a 
great deal of the penalty of abstraction is a nonissue. Nonetheless, state 
machine synthesis is really for a narrow application range, where you're doing 
something simple, well-defined, and probably control-system oriented.

Schematic entry gives you far more insight into what's happening at a 
gate-level. If you're a "hardware" person, this will be a natural way to 
design. You can actually see what the gate implementation is, and this will 
give you a better immediate feel for timing issues, data paths, and simply 
what's actually going on in your design. You can design very, very complex 
logic if you want, and it's easier to optimize the design for the specific 
device you have. It eliminates a lot of the associated abstraction problems of 
HDL's, simply because everything happens at a more primitive level. Also, you 
can instantly see how complex a function is *actually* going to turn out to 
be, so you can either eliminate or redesign the logic if it turns out to be 
too expensive. In a sense, you have more flexibility in what you can design, 
because the tool lets you create logic much more with a specific view to the 
hardware capabilities of the chip. It may help also to de-mystify what's 
happening at a hardware level.

The big downside of schematic entry is that it's very difficult to modify the 
design, still harder to port it to a different device. It basically locks you 
into the device and design you envision at the present. You should also expect 
a lot of debugging because it doesn't isolate you from implementation-level 
errors, i.e. your logic may be right, but how you implemented it in the 
schematic may be faulty, something you can avoid with HDL's. Worse, the 
verification and simulation capabilities are more limited, and third-party 
support is essentially nonexistent. Xilinx' tool furthermore has a whole set 
of frustrating, nonsensical limitations. You should therefore be very 
confident with your schematic capture capabilities before tackling a design 
this way. It's best for the more bleeding edge, oddball designs where you 
aren't overly concerned with design cycle time, and where you don't expect to 
be changing devices any time soon.

Finally, FPGA editor gives you ultimate control, giving you direct access to 
the physical layout and configuration of the device proper. Obviously, this 
means you can program any configuration the device is capable of implementing, 
no matter how bizarre or complex. You can see directly *exactly* what's going 
on, tweak your fitting down to the last detail, specify precisely what 
function blocks, connections, etc. implement which piece, etc.

The negatives are equally clear-cut, namely, you have *NO*: simulation, 
verification, portability, error-checking, or third-party support. Experts 
only need apply, and you'd better know hardware inside and out. Debugging will 
take a long time, and unless you're really careful, you may smoke a component 
or 2. So this is a tool to use only if you're an expert and have some 
freakish, ultra-high-end design where you can't tolerate any sort of 
compromise whatsoever.

Alex Rast
arast@qwest.net
arast@inficom.com

Article: 32983
Subject: Re: Design entry
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Fri, 13 Jul 2001 18:26:09 -0700
Links: << >>  << T >>  << A >>
arast@inficom.com (Alex Rast) wrote:
>...
>HDL's excel in complex but well-defined designs, where you know exactly what 
>...
>The downside of HDL's is that the abstraction isolates you very much from the 
>details of what's going on in the hardware. Typically you don't have ultimate 
>...
>Schematic entry gives you far more insight into what's happening at a 
>gate-level. If you're a "hardware" person, this will be a natural way to 

I think this distinction is completely arbitrary. Actually the ONLY
difference between HDL and schematic entry is how they are visually
presented. You can get an HDL text file which is completely identical
to a schematic and that is how you link schematic entry to P&R anyway.
You get an EDIF file from your schematic entry tool. Viewlogic's
Viewdraw can even generate Verilog from your schematics. You can
instantiate gates in Verilog and put constraints etc. which is what
the schematic does. IOW, if you want to do gate-level structural entry
HDL lets you do it unlike schematic which forces you to only that type
of entry. In HDL you have a lot more freedom. You can design complex
state machines for control blocks  easily and you can be as detailed
and low level as you need for datapath blocks.

Muzaffer



Article: 32984
Subject: Re: WTB:50 Mhz 24 CHANNEL LOGIC ANALYZER only $199
From: "Ivan Vernot" <ivernot@ozemail.com.au>
Date: Sat, 14 Jul 2001 13:30:50 +1000
Links: << >>  << T >>  << A >>
Thank you for the reply.
I'm sure that you could do this with an FPGA - however I'm just a poor
embedded systems engineer (;-) ) who is closer to the software than the
hardware side of things and this 'little' development is way beyond me!

Anyone out there interested in developing a kit or something?

Kind Regards,
Ivan Vernot

"Ulf Samuelsson" <ulf@atmel.dot.com> wrote in message
news:2Yf27.3790$5t1.2052@nntpserver.swip.net...
> you could do this inside an FPGA!
>
>
> --
> Best regards,
> ulf at atmel dot com
> The contents of this message is intended to be my private opinion and
> may or may not be shared by my employer Atmel Sweden
>
> "Ivan Vernot" <ivernot@ozemail.com.au> skrev i meddelandet
> news:Ezj17.49677$Rr4.38763@ozemail.com.au...
> >
> > Hello FPGA Gurus,
> > I've been trolling the Google archives for this news group looking for a
> > Logic Analyzer that I may built as a kit (or buy cheaply)
> >
> > I came across reference in Oct 1996 for a company - 'ProBoard Circuits'
> > which sell a cheap logic analyzer.
> > Does anyone have any experience with this Company and have any further
> > contact info?
> > Can anyone point me in the right direction in being able to find a low
> cost
> > login analyzer for, relatively' low speed work.
> >
> > I am looking for something pretty basic - around 8 channels (min) -
> perhaps
> > 20 MHz max freq.
> > Any ideas?
> >
> > TIA
> > Ivan
> >
> >
> >
> >
>
>



Article: 32985
Subject: Re: Xilinx BRAM failures
From: Bob Perlman <bob@cambriandesign.com>
Date: Sat, 14 Jul 2001 04:07:05 GMT
Links: << >>  << T >>  << A >>
On 12 Jul 2001 12:01:04 -0700, Achlys4now@yahoo.com (Achlys) wrote:

>Is anyone experiencing block ram failures in Xilinx Virtex-E devices?
>We've seen a condition where different bit files will cause hard
>failures on a small percentage of the parts. The block rams are
>configured as 32-bit wide FIFO's; certain nibbles of the fetched data
>seem to be from the previous clock cycle. Locking the block RAM
>locations in the design doesn't always help; some devices still fail,
>some pass. Re-synthesising the design helps sometimes but not always.
>Working boards will fail with new bit files. We've seen the failure on
>multiple parts and on multiple designs.
>
>Is anyone experiencing anything similar or other unexplained failures
>with Virtex-E parts?

Is this FIFO asynchronous, i.e., are the read and write clocks
mutually asynchronous?  If so, and if you're meeting static timing,
I'd bet on a problem in the control logic.  A resynchronization
problem isn't going to show up as a static timing error, but it
certainly can sink your design.

Bob Perlman


Article: 32986
(removed)


Article: 32987
Subject: Re: Help needed: why am I getting device programming errors on Webpack.
From: www@plexus-technologies.com (Dean)
Date: Sat, 14 Jul 2001 05:48:11 GMT
Links: << >>  << T >>  << A >>
On 13 Jul 2001 17:36:25 GMT, just as I was about to see how much duct tape
you REALLY need to stop a gerbil from exploding, mikeandmax@aol.com
(Mikeandmax) distracted me by babbling thusly:

>Sounds like you are connecting a couple of 'deadbugs' together - and also
>sounds like you've got it pretty close to 'right'.  Did you make sure to
>adequately decouple and hook up power the the device - when doing a simple
>read, not much current consumed, not much noise generated, but writing is a
>whole other ballgame, onchip programming supply ramps up and sucks plenty of
>current - poor regulation can cause the types of intermittent errors you are
>having.  I figure you may have tried more than one device also?
> >

Yes all chips behave the same. Why do I get the feeling you need a small
power station hooked up to these things when you want  to program them? I
have two lengths of kynar wire connecting from the JTAG header to pads which
connect directly to the power and ground planes on the processor board. 

A 7805 powers the entire processor board without dramas.

Is this not enough? This thing really sucks THAT much juice?

Article: 32988
Subject: Re: FPGA Express search path
From: anilkateel@rediffmail.com (Anil)
Date: 14 Jul 2001 00:13:54 -0700
Links: << >>  << T >>  << A >>
There is no search path concept in FPGA Express/Compiler.

So when you include a verilog file using `include directive 
you need to make sure that the file is in the same directoy 
where as the original verilog file exists.

There are 3 solutions for this :-
(1)If suppose u have a file /a/b/c/test.v which has a `include x.v
   and if x.v is not there under /a/b/c/ DIRECTORY then just create 
   a link to x.v under /a/b/c/ pointing it to it's original location.
   link -s <original x.v path>/x.v /a/b/c/x.v
(2)Copy x.v to /a/b/c/ directory. 
(3)Just chnage `include x.v to `include <locattoin to x.v>/x.v (Hard to do !!!)

-- Anil

Joey Oravec <joey@sun.science.wayne.edu> wrote in message news:<9i5bbh$ias$1@cwis-1.wayne.edu>...
> Hi I've had some bad experiences with dc_shell and Xilinx Virtex/E
> libraries so I'm trying to use FPGA Expree 3.4 which came with Foundation.
> Even though it's Windows based and kind of slow, it's giving way better
> results than dc_shell.
> 
> I'm stuck using fe_shell instead of the GUI. It seems to recognize format
> by the filename extension, and my designs have the more common .vs, .vg,
> .vr extensions. Unlike the GUI, I can specify the format and filename
> within fe_shell.
> 
> Only big probelm so far is migrating my scripts. Normally I do a:
> 
> set search_path "$search_path ../../defines"
> 
> in dc_shell so it can find everything that I `include in code. I set this
> variable in fe_shell and it seemed to have no effect; when I add files it
> was not actually regarding the search path. Is this done differently in
> fe_shell than dc_shell?

Article: 32989
Subject: Re: Altera's ByteBlasterMV cable resistor values (2.2 ohms) ?
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sat, 14 Jul 2001 18:20:21 +1000
Links: << >>  << T >>  << A >>
I just made a byteblasterMV for the acex 1k, and it works:)

The resistors are 100ohms and 2.2k.

The schematic doesn't show any VCC-GND capacitor across the 74HC244,
but i put a 100nF in there anyway.

I assume the max3000 is jtag. Try connecting 1k pull-up resistors
just in case...

Rodo wrote:
> 
> Hi all...
> 
> A friend and I are building this cable to experiment with the MAX3000 series
> chips. The datasheet for the cable shows several 100 ohms resistors in
> series and 2.2 ohms resistors as pull ups. These 2.2 ohms resistors are very
> low to be a pull ups so we called altera to make sure. The tech guy said the
> value was right. Not convinced my friend went to ask a professor who
> happened to have the evaluation board from altera. After looking at the
> schematic for the board the resistors are 2.2K ohms. So, we build the cable
> with the 2.2k values.
> 
> The Max+Plus II software detected the cable but it cannot find any device
> attached. We have a EPM3032ALC44-10 connected and setup as the target
> device. We did supply a 3.3v to all 4 VCC pins in the device and the cable.
> We're gonna go back to ask the professor on Monday if we can take his cable
> apart and make sure the resistor values are right :-). Does anyone know the
> values for the resistors ? Is it 2.2 K or ohms ?
> 
> BTW if we disconnect the cable and check if the device is blank we get a
> cable not found error. With the cable connected it says no device or socket
> empty.
> 
> Any help/comments are welcome.

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\                                       /  /\/\
/__/   / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
\  \  /  Victoria, Australia, Down-Under      \  \/\/
 \__\/                                         \__\/

Article: 32990
Subject: Re: Help needed: why am I getting device programming errors on Webpack.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 14 Jul 2001 10:23:47 +0100
Links: << >>  << T >>  << A >>


Dean wrote:

> I'm trying to program my first Xilinx device - a 95108. I've created the
> jed file, no errors. What I've done is designed a small PCB with a 6-way
> header for the JTAG interface (no pull up resistors - do I really need them?
> Local FAE says no), and two other headers to pull out all the I/O pins so I
> can interface it to the processor board I've added this little board to
> (double-sided tape is a wonderful thing).
>
> I've made sure the connections are right, and am trying to program the
> device. I'm using WebPACK v3.3.
>
> I can apparently erase the device (all entries from the log file):
>

Have you set the ``override write protect'' tick box  when trying to erase the
device ?

I came across this problem with the original 5V devices where occaisonally you'd
get a supposedly new one with its w-prot bit set. This was back in the
pre-JTAGProgrammer days of EzTag. Xilinx had to do a hot fix to EZTag to get
around the problem - basically adding the override thing above.



Article: 32991
Subject: Which Chip Family?
From: safahmy@hotmail.com (SAF)
Date: 14 Jul 2001 05:30:57 -0700
Links: << >>  << T >>  << A >>
Having done some simple projects on Altera EPLDs at college, I am
looking to move into this stuff a bit more seriously. I am not going
to ask the normal newbie questions, as a quick search of this group
covers most things.

What I want to know is:

Given that the idea in my head now is to do with network switching as
a an aim. What Xilinx chip family should I go for? My project might
end up on a PCI card or as a stand alone solution. Should I go for
Virtex or Spartan?

Remember I am starting out, so I need to be able to start small on
whatever it is. Should I just start out with the XC4k as on the XESS
boards? I want to lear as uch as possible in the next 2 months.

Or should I actually o for CPLDs perhaps Coolrunner specifically,
since switching is speed critical?

Any help is well appreciated. I will most probably be using WebPack.

What download cable/development board should I use?

Thanks for your interest.

Suhaib.

Article: 32992
Subject: Real beginner
From: "Pascal Lacroix" <pascal.lacroix2@freesbee.fr>
Date: Sat, 14 Jul 2001 16:08:46 +0200
Links: << >>  << T >>  << A >>
Hello,

I'd like to learn how to use and how to program a chipset like FPGAs. Where
should I look first ? Could someone help me ?

Thanks. Pascal.



Article: 32993
Subject: Re: Design entry
From: emanuel stiebler <emu@ecubics.com>
Date: Sat, 14 Jul 2001 08:14:08 -0600
Links: << >>  << T >>  << A >>
Noddy wrote:
> 
> This brings me to my question? Should I rather be
> attempting to implement my designs in VHDL instead? 

Mix it !
A top level schematic, the units below in VHDL, Verilog, etc..
It's amazing, already magic how easy it is to explain what you're doing
to somebody else, when you can see all functional units, data flow on
one sheet.
And, sometimes you see your own design more clearly ;-)

when you like to go to HDL only, just replace one sheet to a text page.

just my .02 
have fun

Article: 32994
Subject: Re: Downloading file to Xilinx (Vertex_E) FPGA.
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 14 Jul 2001 07:56:59 -0700
Links: << >>  << T >>  << A >>
On Thu, 5 Jul 2001 16:44:13 +0000 (UTC), subodh@best.com (Subodh
Nijsure) wrote:

>Hello,
>
>Is the following sequence to download bit file to Xilinx Vertex_E correct?
>I am using CPLD which to send bit stream to FPGA.
>
>Here are the steps I am doing from my Linux driver that downloads the
>bitstream to the FPGA.
>
>1. Hold PROGRAM high wait for 400 us 
>2. Hold PROGRAM low, monitor the INIT pin, wait for it to go high, this
>will indicate FPGA has cleared the memory.
>
>3. Then hold PROGRAM pin high, CCLK 0, send data bit 0, 
>4. Then hold PROGRAM pin high, CCLK 1, send data bit 0, 
>Repeat steps 3 through 4 for entire .bit file. 
>
>Now monitor the DONE pin if its high everything is okay else FPGA download
>failed.
>
>WHat I have observed is after step 2 above if i wait for 100 us and go
>back and check the INIT pin it has gone low, I haven't sent any data bits 
>to FPGA yet. So if INIT pin has gone low (0) should I still continue to
>send data? 
>Also in steps 3 and 4 should one be checking if INIT has gone low or DONE
>has gone high?
>
>/Subodh Nijsure


After you pull PROGRAM high, you need a *long* wait before you can
begin clocking data. The delay depends on the device... check the data
books.

John


Article: 32995
Subject: Re: Pins state on Spartan XL before config.
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 14 Jul 2001 08:00:00 -0700
Links: << >>  << T >>  << A >>
On Tue, 10 Jul 2001 19:14:29 +0200, Falk Brunner <Falk.Brunner@gmx.de>
wrote:

>Lionel DORIS schrieb:
>> 
>> I would like to know which is state of all I/Os before the configuration is
>> loaded in FPGA.
>
>They are all tristated.
>

But beware 'dual use' pins like HDC and LDC!

John




Article: 32996
Subject: Re: Design entry
From: Neil Franklin <neil@franklin.ch.remove>
Date: 14 Jul 2001 17:19:57 +0200
Links: << >>  << T >>  << A >>
arast@inficom.com (Alex Rast) writes:

> In article <994923743.528258@turtle.ru.ac.za>, "Noddy" <g9731642@campus.ru.ac.
za> wrote:
> >Hi,
> >
> >(using Foundation ISE). This brings me to my question? Should I rather be
> >attempting to implement my designs in VHDL instead? My experience with VHDL
> >is the Designer's Guide to VHDL!
>
> Most people, I'm sure, are going to tell you to use HDL's.
>
> You have 4 basic options: HDL, state machine, schematic, or FPGA editor. These

> roughly correspond to decreasing levels of abstraction.

May I add a 5th option: JBits.


> HDL's
> They let you describe your logic in
> a source-code-like manner,
>
> The downside of HDL's is that the abstraction isolates you very much
>
>
> Finally, FPGA editor gives you ultimate control
>
> The negatives are equally clear-cut, namely, you have *NO*: simulation,
> verification, portability, error-checking, or third-party support. Experts
> only need apply, and you'd better know hardware inside and out. Debugging will

> take a long time, and unless you're really careful, you may smoke a component
> or 2. So this is a tool to use only if you're an expert and have some
> freakish, ultra-high-end design where you can't tolerate any sort of
> compromise whatsoever.

JBits also gives you FPGA Editor level control, but using an HDL like
source code with all the advantages of replication structures (good
for data paths).

I managed to get it to work despite being a beginner (previously only
74xx stuff) by simply reading *thoroughly* the Virtex data sheet and
the JBits docs, plus a few mails to Xilinx JBits group. The JRoute
component allows routing without danger of accidently killing chips.

Also runs on any machine with Java support. I develop on Linux, no NT
or Solaris.

Negatives are: simulation is limited to DeviceSimulator, essentially
step the clock through your design, whatching what it does. No
protability (only Virtex, and Spartan-II of sizes that also exist in
Virtex). And code is fairly verbose (you set everything), and you need
to do 100% hand placing (routing is automated). So it is fairly time
intensive.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 32997
Subject: Re: WTB:50 Mhz 24 CHANNEL LOGIC ANALYZER only $199
From: elex3305@yahoo.com (Wally)
Date: Sat, 14 Jul 2001 16:44:36 GMT
Links: << >>  << T >>  << A >>

Go to www.bitscope.com  They have a kit that includes a logic analyzer
and a DSO in one box. I have just started using it and it works great.
The software is just adequate, would be nice to have more but it does
work.

Wolly


Article: 32998
Subject: Re: Shift and Add Multiplier With Signed Numbers
From: "Steve Casselman" <sc@vcc.com>
Date: Sat, 14 Jul 2001 10:51:44 -0700
Links: << >>  << T >>  << A >>
I have to disagree. A booth multiplier is more efficient than a regular
shift and add. In the 4000 I was able to fit a booth multiplier in the same
area as a normal shift and add (which does not use all the inputs in a 4 bit
LUT and the recoding just takes two three-LUTs and an inverter). As you know
one of our demos is the mandelbrot hardware. You can "unroll" the booth
multiplier and pipeline it to save 1/2 the area.

Steve



"Ray Andraka" <ray@andraka.com> wrote in message
news:3B4E8927.BF2AB802@andraka.com...
> Booth recoding won't help much in this case.  A scaling accumulator
> multiplier is a single accumulator with the feedback shifted.  It is a
> serial by parallel multiplier, that uses a conventional adder.   Booth
> recoding seeks to reduce the number of partial products by recoding
> strings of '1' bits into an equivalent 1, -1 and zeros.  The result is
> that you can reduce the number of partial products to be combined in an
> adder tree, which in turn reduces the size of the tree.  Since the
> scaling accumulator multiplier is shifting once and adding for N cycles,
> you essentially are doing all the partial products regardless of whether
> or not they are zero.  You could conceivably use Booth recoding in this
> case to reduce the number of cycles, but in a practical sense, the added
> complexity to the circuit would outweigh the benefit (one could use two
> scaling accumulator multipliers, or go to a 2 bits/clock version to get
> on average a better speedup for less area and complexity).  All he has
> to do is subtract the partial product corresponding to the MSB of the
> serial input and sign extend the parallel input to handle signed
> muliplicands.
>
> Rob Finch wrote:
>
> > Try using Booth recoding.
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>
>



Article: 32999
Subject: Re: Design entry
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Sat, 14 Jul 2001 11:45:21 -0700
Links: << >>  << T >>  << A >>
Noddy wrote:
> 
> Hi,
> 
> As you've guessed from recent posts, I'm very new to using FPGAs (couple of
> months). I've been spending my time implementing schematic design entries
> (using Foundation ISE). This brings me to my question? Should I rather be
> attempting to implement my designs in VHDL instead? My experience with VHDL
> is the Designer's Guide to VHDL!

If you are getting the job done, don't worry about.
My bias is now towards HDLs, but I also started
with schematics, and that works fine too.

The fact that you asked the question suggests
that you have some interest in HDLs.
If this is true, you might want to start
by writing an HDL testbench for an existing
schematic design. 

 --Mike Treseler



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