1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

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 19025

Article: 19025
Subject: Re: VHDL vs. schematic entry
From: John Larkin <jjlarkin@highlandtechnologySnipThis.com>
Date: Wed, 24 Nov 1999 12:27:44 -0800
Links: << >>  << T >>  << A >>
On Wed, 24 Nov 1999 15:11:57 GMT, Greg Neff <gregneff@my-deja.com> wrote:

>In article <hAo7OGCUqVpuedBjHwKsQ44FTFG5@4ax.com>,
>  John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote:
>(snip)
>> We actually don't spend much time debugging uP code or FPGAs because
>of our
>> philosophy: design carefully, document and comment thoroughly, check
>it before
>> you fire it up, and keep it beautiful at all times. I dislike
>habitual use of
>> simulation because it tends to lead designers toward a hack-and-test
>mode, and
>> one can never really test quality into anything. So far, we've had
>zero
>> hardware/software/FPGA bugs in the products we've shipped that have
>FPGAs.
>>
>> Anyway, we do fairly hairy FPGA designs using schematics, and the
>stuff comes
>> out fast and relatively easy. I just thought *somebody* ought to
>express that
>> opinion.
>>
>(snip)
>
>I think that Ray was commenting on those engineers that use the "burn
>and learn" approach to design, which is very risky and unpredictable.
>If I understand your comment correctly, you are trying to avoid a
>similar "simulate and learn" approach.  Although neither is a good
>design methodology, I would imagine that it would still be better to
>learn at the simulate stage, as opposed to the hardware stage.
>
>The "correct by design" approach (which is what I think you are
>promoting) still requires some sort of method to validate and
>verify "correctness".  Complete specifications, careful and well
>documented designs, and design reviews are obvious requirements to
>implement a correct by design methodology.  Still, I find it hard to
>believe that simulations are not faster and more reliable than manual
>analysis when it comes to validating a design.

Greg,

the final product *must* be thoroughly tested, so this testing is potentially
redundant with FPGA simulation. Lots of things can go wrong in the non-FPGA
hardware and software, so it seems scairy to me to assume that a product works
just because one simulation predicts that it does. If the FPGA design is flat
DOA, and you can't even begin to test the final product, you can blame that
situation on  a) failure to simulate or  b) sloppy design, depending on how you
feel about these things. But the same applies to the PCB layout, the uP code,
and the non-FPGA parts of a design.

Without being *too* obnoxious about it, I think that moderately complex FPGA
designs can be done efficiently using schematics. If they are designed and
checked carefully, any bugs can be found at the product qualification test
level (which we are obliged to do anyway) and, if the design and documentation
are good, fixed quickly and easily.

John


Article: 19026
Subject: Re: implementing TCP/IP on PLD
From: Mark Summerfield <m.summerfield@ieee.org>
Date: Thu, 25 Nov 1999 08:49:33 +1100
Links: << >>  << T >>  << A >>
Donald Gillies wrote:
>
> TCP is an unrealistic thing to implement on an FPGA - no matter what
> the time frame, no matter who is doing it.  A good TCP has some very
> complex sub-algorithms.

Not only are you going to need to explain to the person who has already
stated that he was involved in an implementation in two Xilinx 4044's
that it was just a lucid dream, you're also going to have to convince
Seiko that a hardware implementation of moderate size and cost is
impossible before they sell too many of their S7600 parts:

http://www.seiko-usa-ecd.com/intcir/html/assp/s7600a.html

a 67k gate count for the protocol stack, developed fully in Verilog RTL.

However, I do agree that this is an impossible task for a student
project.  Perhaps a more realistic task would be to buy one of the
Seiko chips, and interface it to an affordable FPGA and/or microprocessor
to implement a higher-layer protocol such as HTTP?

Mark

Article: 19027
Subject: Re: implementing TCP/IP on PLD
From: "Dirk Bruere" <artemis@kbnet.co.uk>
Date: Wed, 24 Nov 1999 23:24:43 -0000
Links: << >>  << T >>  << A >>

Mark Summerfield <m.summerfield@ieee.org> wrote in message
news:383C5D6D.DC4E63D5@ieee.org...

> that it was just a lucid dream, you're also going to have to convince
> Seiko that a hardware implementation of moderate size and cost is
> impossible before they sell too many of their S7600 parts:
>
> http://www.seiko-usa-ecd.com/intcir/html/assp/s7600a.html

Depends what you mean by 'hardware implementation'. Do you mean single chip
micro using a gate array? State machine that is not quite single chip micro,
or 'random logic' with TCP/IP hardwired - no microcode?

> a 67k gate count for the protocol stack, developed fully in Verilog RTL.

> However, I do agree that this is an impossible task for a student
> project.  Perhaps a more realistic task would be to buy one of the
> Seiko chips, and interface it to an affordable FPGA and/or microprocessor
> to implement a higher-layer protocol such as HTTP?

A better project might be using a FPGA as a s/w configurable co-processor
for a standard uP, with (simple) examples of 'C' code being compiled into
configuration data for the FPGA to run it in h/w.

How simple or complex is entirely up to those doing the project. The nice
thing is, the effort is smoothly scalable, from  int a+=1; right through to
FFTs and upwards.

IIRC, Xilinx is/was sponsoring such research in some university. They may
well be able to help.

Dirk


Article: 19028
Subject: Re: Anybody using Lucent OR3TP12?
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Wed, 24 Nov 1999 18:00:20 -0800
Links: << >>  << T >>  << A >>
Have you looked at the Quicklogic core?  Impressive... acts hardwired, has
lots of block ram, doesn't need a big prom, and I think it is cheaper than
anything you will get from Xilinx that will actually hold the core (if you
include the big prom).  Also, they have a 66MHz 64 bit version (embedded
asic).

One thing you might look at when you consider PCI cores is whether you need
a "backup fifo" or is it implemented in the core.  When you get a late
TRDY-false does the core save the data in a hidden register or do you have
to backup your fifo pointer to send it (there is no way you will be able to
stop the fifo from advancing since the signal comes so late).  My impression
is that Xilinx requires a backup fifo.  Also, look carefully at the price of
the part once it is big enough and fast enough to hold the core.

Bruce

Bryan Williams wrote in message <383BA036.7C1188C5@at_smart.net>...
>email address is altered to prevent spam.
>I'd recommend the part only if you hate yourself and are looking for a
>reason to end it all ;)
>
>Jokes aside, we've been trying to use this part, and there's a lot of pain
>Lucent parts brings up many of these points.  Have you found a proto-board
>based on this part? If so, I'd like
>to hear about it, but I don't think it exists because I've spent mucho time
>looking through all the lists at optimagic
>and other sites to no avail.  Like someone else pointed out, Xilinx &
Altera
>make FPGA's and hardly anything else. Lucent makes so
>many types of products it would be nearly impossible for one list them all.
>Who's gonna try harder?
>
>We're in the process of getting Xilinx's PCI design kit. One thing I like
>about it is the ability to target anything from a cheap Spartan
>(is there really any FPGA competition for Spartan's market?) to the biggest
>Virtex. I'll know more when it's in hand.
>
>Lucent's tools are now behind the times. Xilinx bought Neocad, old news,
but
>the Lucent back-end tools haven't changed a lot since then.
>A bit rough around the edges.  I'm not sure how Lucent explains their
>think they took the existing codebase and found new programmers to take
over
>the code and go in their own direction, but I'm speculating.
>
>A problem you'll immediately find is that so far as I can tell the OR3TP12
>is EXCLUSIVELY FOR VHDL/Verilog.  That's the way the
>core parameters are passed and it's your only option.  The core setup tool
>is a pain too since you can't save your settings to revise them later.
>It fleshes out a VHDL/Verilog template and you can't go back to the GUI to
>tweak settings later. Write them down ! We're using Synplify for the
>VHDL, FYI.
>
>There's a lot of nifty things the hardwired core allows you to do, but
>there's also the drawback of it being considerably more effort for them to
>roll
>out new chips. Your only option right now is the pared-down OR3C/T55 -sized
>device (sans about 4 rows for the PCI core) with other parts "coming soon
>now"
>for quite some time now. Our local apps engineer went back to the plant to
>"help roll out the next device" or something, which left us without
>good support. The hardwired core has many bugs, and the downside of these
>bugs is that it's not a simple fix being hardwired and all.
>
>The core setup software had a bug we were stuck with for quite some time
>before receiving an update -- the BYTES were OUT OF ORDER in the 32-bit
>words.
>How the hell do you miss something like that in testing? Luckily, it WAS
>software.
>
>My guess is that if you go with the part you will feel very alone with
>whatever problems you come across. We sure do.
>
>One good way to judge your FPGA vendor: go see how many application notes
>they have. Lucent's got maybe 10 or 20 total on the web. Xilinx has
probably
>a thousand
>or more scattered across the Xcell Journal and general app notes. I like
>that.
>
>The Xilinx PCI design kit comes with a board based on the core and a
>reference design. PCI is complicated as hell and that reference can save
>MONTHS.
>BW
>
>Edward Wallington wrote:
>
>> Hi,
>> has anyone put a design into production using the OR3TP12 on a card in a
>> PC?
>> (this is Lucent's part FPGA, part hardwired ASIC PCI core)
>>
>> Which synthesis route / tools did you use?
>> Any gotcha's ? Did it work perfectly?
>>
>> Thanks
>>
>> Ed.
>>
>> --
>> Edward Wallington - Chief Hardware Engineer
>> Cambridge Research Systems Ltd.
>> Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719
>> http://www.crsltd.com
>


Article: 19029
Subject: Re: Obselete processor substitutes
Date: Thu, 25 Nov 1999 15:26:00 +1300
Links: << >>  << T >>  << A >>
log wrote:
>
> This might not be strictly an FPGA question, but does anyone know if it is
> currently possible to get obselete microprocessors emulated on fpgas or
> other platforms.  I need a seamless cross over from an old one time 8749 to
> something which looks electronically the same when in circuit.

It is possible, but not practical.
The 8749 should still be procurable, and even on upward slope of
a bathtub price curve, will cost less than a FPGA.

FPGA's do not come in DIP40 packages, so a adaptor PCB is needed,
with a min of QFP.fpga + Serial Loader PROM, and possibly a
MEMORY chip for CODE storage.

A better approach is to use a 89C51 to emulate a 8749, when they finally
dry up completely, and even these are 99% compatible.
We have done macros to allow ASM48 -> ASM51 porting.

- jg

--
======= Manufacturers of Design Tools for uC and PLD  =====
* IceP2051 - Full Speed ICE, for 1K,2K,4K 20 Pin FLASH controllers
* OptoISP  - Safe, fast In System Program of 89S, 90S, 17C devices
=> http://www.DesignTools.co.nz/winner51.htm  for highlights


Article: 19030
Subject: UTOPIA Interface on FPGA
From: Franck Thierry <fthierry@videotron.ca>
Date: Wed, 24 Nov 1999 22:09:44 -0500
Links: << >>  << T >>  << A >>
I have to interface a regular micro to an UTOPIA 1.0 Interface using a
FPGA. I've tried to find out an application note describing this kind of
interface on different FPGA Web Site, but it seems that today, everybody
has IP stuff, and you have to buy it (it's quite expensive...)

Is someone there has any reference or good URL about that,

Thanks,

-- Franck

Article: 19031
Subject: Re: VHDL vs. schematic entry
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 25 Nov 1999 03:51:48 GMT
Links: << >>  << T >>  << A >>
In article <S0Y8OAj5xsgDRoKM1sl4YlEpHfzg@4ax.com>,
John Larkin <jjlarkin@highlandtechnologySnipThis.com> wrote:

> Greg,
>
> the final product *must* be thoroughly tested,

Yup, you gotta test every "shall" in the spec.

> so this testing is potentially
> redundant with FPGA simulation.

True.

> Lots of things can go wrong in the non-FPGA
> hardware and software,

Murphy is an optimist.

> so it seems scairy to me to assume that a product works
> just because one simulation predicts that it does.

I don't think we are talking about making that kind of assumption, or
saying that FPGA functionality can be extended to imply system
functionality.  Don't get me wrong here, I don't entirely disagree with
your opinion.  Certainly, a simulation is no good if the stimulus does
not properly mimic what actually is present in the system (garbage in,
garbage out).  This is a *big* problem with simulation (just ask the
SPICE guys).

> If the FPGA design is flat
> DOA, and you can't even begin to test the final product, you can
blame that
> situation on  a) failure to simulate or  b) sloppy design, depending
on how you
> feel about these things. But the same applies to the PCB layout, the
uP code,
> and the non-FPGA parts of a design.
>

Hmmm. I don't think that I'm saying that simulation is a replacement
for sound design.  I think the "correct by design" approach is the best
way to go, since there is less time spent on fixing things later.
Still, I have been doing this stuff for too long to believe that anyone
can produce a 25-page FPGA schematic, including state machines, digital
PLLs, etc., and expect it to run right out of the chute.

> Without being *too* obnoxious about it,

No problem, I like a good discussion :)

>I think that moderately complex FPGA
> designs can be done efficiently using schematics. If they are
designed and
> checked carefully, any bugs can be found at the product qualification
test
> level (which we are obliged to do anyway) and, if the design and
documentation
> are good, fixed quickly and easily.
>

I mostly agree with this statement.  I am very comfortable with
schematic entry (I use Viewlogic), which is why I am questioning the
need to go to VHDL. I am not convinced that I need VHDL, which is why I
posted the set of questions.  I appreciate your opinions on this.

However, the VHDL question is separate from the simulation issue that
we seem to be debating. I am convinced that running simulations on my
schematic based designs helps to validate portions of a design that
can't be tested, such as forcing a state machine to an illegal state.
Also, I know that simulations have saved me lots of time in
troubleshooting quirky problems, where I needed to have a high degree
of visibility into the logic.

Simulation is not, and never will be, a replacement for proper design
methodology or thorough system testing. I view simulation as another
tool in my toolbox, but I wouldn't want give up that tool.  For
example, I had a packet converter design that was experiencing a bit
error rate of about 1 in 100,000.  On the test bench, everything looked
perfect on the instrumentation.  I ran some simulations, and found that
during entry I had incorrectly wired a gate that was there to handle a
low-probability boundary condition.  I fixed the gate, and the bit
errors were gone.  I would have *never* figured that out with a scope
test bench.

Bottom line is that I agree with your statements about schematic design
methodology, but I don't agree that simulation is a bad thing (if it is
used properly).

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Sent via Deja.com http://www.deja.com/

Article: 19032
Subject: Re: VHDL vs. schematic entry
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Wed, 24 Nov 1999 20:24:55 -0800
Links: << >>  << T >>  << A >>
On Thu, 25 Nov 1999 03:51:48 GMT, Greg Neff <gregneff@my-deja.com>
wrote:

|However, the VHDL question is separate from the simulation issue that
|we seem to be debating. I am convinced that running simulations on my
|schematic based designs helps to validate portions of a design that
|can't be tested, such as forcing a state machine to an illegal state.

Greg,

that statement intrigued me. Around here, we've debated some about the
'illegal state' issue. The positions are...

1. Any state machine should be able to walk its way out of any illegal
state into a correct sequence

or

2. Bull! If something's impossible, you don't need to worry about it.
If a state machine gets into an impossible state, then the FPGA is
broken. After all, if software gets into an impossible state (like the
PC in the middle of a data table or somesuch) then it's crashed.

(sorry about bringing up an even-less relevant point!)

Ideas?

John

==

A little nonsense now and then,
is cherished by the wisest men.

- Willy Wonka

Article: 19033
Subject: Re: VHDL vs. schematic entry
From: Robert Sefton <rsefton@home.com>
Date: Thu, 25 Nov 1999 04:27:25 GMT
Links: << >>  << T >>  << A >>
John Doe wrote:
>
> VHDL or Verilog is the only way to go for many reasons.
>
> 1. Re-use is as simple as cut and paste (almost)

As many have pointed out in these threads, re-use is in many ways
still a pipe dream. It works well for a limited number of
functions if someone takes the time to write a fully parameterized
(and usually FPGA vendor-specific) library. Then you still usually
have to check what the synthesis tool spit out to make sure it
didn't do something stupid. Cut and paste, or copying and
modifying modules, is unfortunately the way it usually goes in my
experience. But that's not the way re-use was envisioned by the
VHDL creators. Look at the IP market. A loser business if there
ever was one, and one reason is that most designs require some
kind of special tweak to most common functions. The other big
reason most companies don't buy IP is that they want to own their
technology, and that comes into play at the individual designer
level as well. How can I call this my design and be responsible
for maintaining it if someone else designed half of it?

> 2. Portability - most schematic entry tools that I know of use vedor
> specific libraries (I definately do not recommend this).

I really don't buy the portability argument for FPGAs. To really
take advantage of an architecture you end up with a lot of
vendor-specific code. Most code is portable between simulation
tools as long as the vendor libraries are fully compliant, but a
lot of code is also Synthesis tool-specific. Overall this argument
fails for FPGAs.

> 3. Simulation was made so much easier (this alone is an excellent reason to
> change over).

Agreed.

> snip

Personally I don't think detailed knowledge of the language is
needed to use an HDL effectively. The real value that a design
engineer adds is at a higher level than writing code (or entering
a schematic). The real work is at the system level, writing a good
spec and doing the high-level design. Once that's done a monkey
can code it. Writing a good test bench and writing device models
requires thorough knowledge of the language. Design entry, in my
opinion, does not. Once you have an intelligent partition (part of
the high-level design process), as long as you format your code so
synchronous design rules, you can do some serious damage with a
small subset of the language. If you're a good designer at the
schematic level you'll be a good designer using an HDL. If you
want to ease the transition hire an expert to write your test
benches until you're comfortable with the methodology.

RJS

Article: 19034
Subject: ALTERA EPC2 Configuration Help needed!
From: Volker Kalms <ea0038@uni-wuppertal.de>
Date: Wed, 24 Nov 1999 20:30:03 -0800
Links: << >>  << T >>  << A >>
Hi all,

Since a quarter of a year I discover the beatiful world of
AHDL and VHDL. Until now everithing worked fine. But now I would
be very grateful for a little help.

Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured
by Ing. Buero Lindmeier) in my hands. This evaluation board contains
an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the
ALTERA MAX+plusII (v 9.1) software......no problem to this point.

Two weeks ago I purchased an configuration EPROM (EPC2LC20), which
could optional plugged into my evaluation board.I set up the MAX plus
JTAG chain due to the requirements (as far as I would say), performed
an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus
detected the additional device in the JTAG Chain.
But when I try to Program the .pof file to the EPROM I get the message:
Unrecognized device or socked empty.

What am I doing wrong????? From my point of view I changed nearly every
parameter in the MAX plus setup.

I hope there is somebody out there, who could give me a hint how to get
this EPROM configured.

Best regards,

Volker

Article: 19035
From: Volker Kalms <ea0038@uni-wuppertal.de>
Date: Wed, 24 Nov 1999 20:52:43 -0800
Links: << >>  << T >>  << A >>
Hi all,

Since a quarter of a year I discover the beatiful world of
AHDL and VHDL. Until now everithing worked fine. But now I would
be very grateful for a little help.

Lately I got an FPGA evaluation board (DIGILAB 10K10, manufactured
by Ing. Buero Lindmeier) in my hands. This evaluation board contains
an ALTERA EPF 10K10LC84-4. To configure this FLEX device I use the
ALTERA MAX+plusII (v 9.1) software......no problem to this point.

Two weeks ago I purchased an configuration EPROM (EPC2LC20), which
could optional plugged into my evaluation board.I set up the MAX plus
JTAG chain due to the requirements (as far as I would say), performed
an JTAG Chain Info in the Multi-Device JTAG Chain Setup and MAX plus
detected the additional device in the JTAG Chain.
But when I try to Program the .pof file to the EPROM I get the message:
Unrecognized device or socked empty.

What am I doing wrong????? From my point of view I changed nearly every
parameter in the MAX plus setup.

I hope there is somebody out there, who could give me a hint how to get
this EPROM configured.

Best regards,

Volker

Article: 19036
Subject: Re: implementing TCP/IP on PLD
From: Mark Summerfield <m.summerfield@ieee.org>
Date: Thu, 25 Nov 1999 18:35:59 +1100
Links: << >>  << T >>  << A >>
Dirk Bruere wrote:
> Depends what you mean by 'hardware implementation'. Do you mean single chip
> micro using a gate array? State machine that is not quite single chip micro,
> or 'random logic' with TCP/IP hardwired - no microcode?

Well, I haven't seen iReady's code, but if it's written entirely in
Verilog RTL, requires 67k gates, and is technology and library independent
(all their claims), then I think it qualifies as a hardware implementation.
It includes TCP, UDP, IP and PPP implementations, and a serial interface.
It also appears to require 20k of external memory as a buffer for packets.
And an external microprocessor (or equivalent) to actually control it.

I would assume that it contains many state machines, and a lot of "random
logic".  And maybe some simple microcode for some of the state machines,
I guess.  I don't actually understand the distinction you're trying to
draw -- all these are valid digital design techniques which result in
"hardware".

You can decide for yourself if you think it qualifies as a hardware

Mark

Article: 19037
Subject: Re: implementing TCP/IP on PLD
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 25 Nov 1999 08:10:35 GMT
Links: << >>  << T >>  << A >>
"Dirk Bruere" <artemis@kbnet.co.uk> writes:

(snip)

>Depends what you mean by 'hardware implementation'. Do you mean single chip
>micro using a gate array? State machine that is not quite single chip micro,
>or 'random logic' with TCP/IP hardwired - no microcode?

Oh no, the microcode myth again.  Is there something wrong with it if it
is microcoded?  It is possible to build slow vertically microcoded
processors, but it is also possible to build fast horizontal microcoded
processors.  Many processors could be build to run about as fast with
about the same amount of logic microcoded or hardwired.

However, for TCP/IP I would suggest a simple vertical (small instruction
word) processor, almost a simple FSM (state machine) implementation.
In FPGA with an external ROM it might not be bad.  You could even write
a C compiler for it!

-- glen


Article: 19038
Subject: Re: Programming Virtex device via JTAG
From: Michael Schmid <mlschmid@iis.fhg.de>
Date: Thu, 25 Nov 1999 09:20:25 +0000
Links: << >>  << T >>  << A >>
Tom McLaughlin wrote:
>
> Michael,
> Thanks for the advice.  I'm still having problems.  We didn't design the board
> which is one of the problems.  One thing I noticed is that you guys put the
> config pins on "000" for configuration.  We put them on 101 for "JTAG mode"  I
> thought that is what it had to be on to config through the JTAG port.  Again,
> the JTAG programmer software says that the device is programmed, but it is like
> the device never goes through it's startup sequence.  DONE never goes high.
> When I have access to the board again, I'll try configuring with the pins on
> "000".
>
> The other thing I noticed is that you mention the program pin.  We don't
> manipulate this pin.  Should we???  You mention that it is for PROM
> configuration.  Again, we are trying to program via JTAG.  Should we have to
> pull the PROGRAM pin low and then let it go high to program via JTAG???
> Tom
>
> >
> >
> > Hi Tom,
> >
> > We'v done JTAG configuration of virtex
> > XCV300 with  XChecker and also with a
> > selfmade interface for parallelport
> > (Application Note Xilinx). There were no
> > problems. I think the pullup on init is
> > ok (we have the same).
> > I will tell you the other configuration
> > pins for orientation:
> >
> >

Hi Tom,

I don't know exactly if the program pin
is necessary in your BSCAN-Mode (101).
I'v read in the Virtex Manual and found
on side 21 a description of
configuration sequence. I think if you
hold program low the FPGA will do
nothing exept resetting its memory. If
then program goes high the FPGA is ready
for configuration.

Our program Signal is everytime
available (low, high after 100ms) in
PROM or JTAG Configuration. Maybe this
is the case it works?

Michael

Article: 19039
Subject: Ph.D. student position: Comp. Arch. Modelling & Simulation (Amsterdam)
From: andy@poseidon.wins.uva.nl (Andy Pimentel)
Date: 25 Nov 1999 09:55:38 GMT
Links: << >>  << T >>  << A >>

FACULTY OF MATHEMATICS, COMPUTER SCIENCE, PHYSICS AND ASTRONOMY
University of Amsterdam

has an opening for a

PH.D. STUDENT
for 38 hours per week (ref. nr. 15075)

The Computer Architecture & Parallel Systems Group at the Faculty of
Mathematics, Computer Science, Physics and Astronomy of the University of
Amsterdam has an opening for a Ph.D. student in the area of embedded computer
architecture modelling & simulation. The Ph.D. student will participate in the
SESAME (Simulation of Embedded System Architecture for Multilevel Exploration)
project which aims at the development of a simulation workbench for the design
space exploration of programmable embedded media systems. This project, which is
funded by the Dutch government as part of the project called 'Methods and
Architectures for Programmable Embedded Media Systems', is performed in close
collaboration with Philips Research Laboratories and Delft University of
Technology.

TASKS: research on and development of methods and techniques for abstract
computer architecture simulation in the context of embedded systems.

REQUIREMENTS: * M.Sc. in computer science or electrical engineering
* decent knowledge of computer architecture
* preferably (not a must) some expertise in the field of
(computer architecture) simulation

The Ph.D. student will obtain a temporary research position for four years
at the Faculty of Mathematics, Computer Science, Physics and Astronomy of
the University of Amsterdam, for 38 hours per week. The gross monthly
salary is NLG 2,195.- for the first year, growing up to NLG 3,919.- for the
last year, PLUS an extra allowance. The holiday allowance will be 8% of the
annual income.

INFORMATION on our group and the ongoing research: www.wins.uva.nl/research/arch/

APPLICATION: Applications, quoting job reference number (15075) and marked
'confidential', should include a curriculum vitae, a list of course grades
and a list of publications, and should be sent to dr. A.D. Pimentel, University
of Amsterdam, Faculty of WINS, Kruislaan 403, 1098 SJ Amsterdam, The Netherlands.
Inquiries and applications sent by e-mail (ASCII or postscript) should be directed
to andy@wins.uva.nl
--
Andy Pimentel                     x    #define R(x,y) (x<<y|(x<<y&32)>>5)&31
Computer Architecture &       X  :x:   main(i){putchar(i+64);if(~i&16)if(~0\
Parallel Systems Group,      |X|  x    +i&&~3+i)main(R((~i&15),2));else mai\
University of Amsterdam       X        n(R((i|i<<1|i<<2),1));else puts("");}

Article: 19040
Subject: Re: Trouble with ATMEL's AT40K20
From: "Filip S. Balan" <balan@uni-mb.si>
Date: Thu, 25 Nov 1999 11:04:25 +0100
Links: << >>  << T >>  << A >>
Andy Peters wrote in message <81h3o8$17ab$1@noao.edu>...
>Filip S. Balan wrote in message <81g8ar$h47$1@strelovod.uni-mb.si>...
>>Andy Peters wrote in message <81ehfm$15c6$1@noao.edu>...
>>>Filip S. Balan wrote in message <81dm75$jt9$1@strelovod.uni-mb.si>...
>>>>>>**Symplify (simulates the HDL design fine all the time)
>>>>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>>I missed 1 SW:
>>>>Symplify & Aldec Active-VHDL (simulates the HDL design fine all the time)
>>>
>>>
>>>Did you use timing constraints and are they being met?
>>>
>>
>>
>>Think it is not important. The input of the shift register is at one input
>>pin
>>and the output of the shift register (last bit) at another (output) pin. A
>>logic
>>"1" should after some time (Tclk * N+eventual timing problems) cause a
>logic
>>"1" and a "0"  a "0".
>>I used this simple TEST design just for this insensibility (if the delay is
>>not important to me).
>>But the output is sometimes (in dependence of cell positions) stuck at "0"
>>or "1" (it does not change)!
>
>perhaps if you post your code...
>
>
>--
>-----------------------------------------
>Andy Peters
>Sr Electrical Engineer
>National Optical Astronomy Observatories
>950 N Cherry Ave
>Tucson, AZ 85719
>apeters (at) noao \dot\ edu
>
>The secret of Slurm is on a need-to-know basis.
>
>
>

Hope names in the slovenian language aren't to hard:
ura = clock
vhod = input
izhod = output

regards

Filip S. Balan

The following is the code for a 16-bit shifter block.
********************************************************

LIBRARY ieee;
USE ieee.std_logic_1164.all;

entity pom_blok is
port
(
ura, reset, vhod: in std_logic;
izhod: out std_logic
);
end pom_blok;

architecture pom_blok of pom_blok is
component sh_reg
port

SHIFTOUT :  out std_logic;
CLK :  in std_logic;
RN :  in std_logic;
SHIFTIN :  in std_logic
);
end component;
SIGNAL tmp_sig_1: std_logic;
SIGNAL tmp_sig_2: std_logic;
SIGNAL tmp_sig_3: std_logic;
SIGNAL tmp_sig_4: std_logic;
SIGNAL tmp_sig_5: std_logic;
SIGNAL tmp_sig_6: std_logic;
SIGNAL tmp_sig_7: std_logic;
SIGNAL tmp_sig_8: std_logic;
SIGNAL tmp_sig_9: std_logic;
SIGNAL tmp_sig_10: std_logic;
SIGNAL tmp_sig_11: std_logic;
SIGNAL tmp_sig_12: std_logic;
SIGNAL tmp_sig_13: std_logic;
SIGNAL tmp_sig_14: std_logic;
SIGNAL tmp_sig_15: std_logic;
SIGNAL tmp_sig_16: std_logic;
SIGNAL tmp_sig_17: std_logic;
BEGIN
tmp_sig_1 <= vhod;
izhod <= tmp_sig_17;

r1:sh_reg port map (
SHIFTOUT => tmp_sig_2,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_1
);
r2:sh_reg port map (
SHIFTOUT => tmp_sig_3,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_2
);
r3:sh_reg port map (
SHIFTOUT => tmp_sig_4,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_3
);
r4:sh_reg port map (
SHIFTOUT => tmp_sig_5,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_4
);
r5:sh_reg port map (
SHIFTOUT => tmp_sig_6,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_5
);
r6:sh_reg port map (
SHIFTOUT => tmp_sig_7,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_6
);
r7:sh_reg port map (
SHIFTOUT => tmp_sig_8,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_7
);
r8:sh_reg port map (
SHIFTOUT => tmp_sig_9,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_8
);
r9:sh_reg port map (
SHIFTOUT => tmp_sig_10,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_9
);
r10:sh_reg port map (
SHIFTOUT => tmp_sig_11,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_10
);
r11:sh_reg port map (
SHIFTOUT => tmp_sig_12,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_11
);
r12:sh_reg port map (
SHIFTOUT => tmp_sig_13,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_12
);
r13:sh_reg port map (
SHIFTOUT => tmp_sig_14,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_13
);
r14:sh_reg port map (
SHIFTOUT => tmp_sig_15,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_14
);
r15:sh_reg port map (
SHIFTOUT => tmp_sig_16,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_15
);
r16:sh_reg port map (
SHIFTOUT => tmp_sig_17,
CLK => ura,
RN => reset,
SHIFTIN => tmp_sig_16
);
end toplevel;


Article: 19041
Subject: Re: Programming Virtex device via JTAG
From: Bill Blyth <wdblyth@my-deja.com>
Date: Thu, 25 Nov 1999 10:27:46 GMT
Links: << >>  << T >>  << A >>
In article <383AE573.C80AF8FE@arl.wustl.edu>,

As far as I know, the state of the mode pins does not matter. On my own
board the mode can be either 111 or 110 (slave serial or selectmap) and
in either state can be programmed over JTAG.

I do notice that if the device is already configured, DONE does not
change. I suspect that the configuration over JTAG is a partial one.

I always have INIT pulled up because the device will indicate an error
by pulling it low. PROG does not have to be toggled to get JTAG to work.
Tom McLaughlin <tomm@arl.wustl.edu> wrote:
> Michael,
> Thanks for the advice.  I'm still having problems.  We didn't design
the board
> which is one of the problems.  One thing I noticed is that you guys
put the
> config pins on "000" for configuration.  We put them on 101 for "JTAG
mode"  I
> thought that is what it had to be on to config through the JTAG
port.  Again,
> the JTAG programmer software says that the device is programmed, but
it is like
> the device never goes through it's startup sequence.  DONE never goes
high.
> When I have access to the board again, I'll try configuring with the
pins on
> "000".
>
> The other thing I noticed is that you mention the program pin.  We
don't
> manipulate this pin.  Should we???  You mention that it is for PROM
> configuration.  Again, we are trying to program via JTAG.  Should we
have to
> pull the PROGRAM pin low and then let it go high to program via
JTAG???
> Tom
>
> >
> >
> > Hi Tom,
> >
> > We'v done JTAG configuration of virtex
> > XCV300 with  XChecker and also with a
> > selfmade interface for parallelport
> > (Application Note Xilinx). There were no
> > problems. I think the pullup on init is
> > ok (we have the same).
> > I will tell you the other configuration
> > pins for orientation:
> >
> >
>
>

--
-----------------------------
Alpha Data
-----------------------------

Sent via Deja.com http://www.deja.com/

Article: 19042
Subject: R: How to use multiple resets?
From: Mark Harvey <mark.harvey@farsystems.it>
Date: Thu, 25 Nov 1999 11:43:27 +0100
Links: << >>  << T >>  << A >>


> We are using Spartan-XL and we intend to use TWO individual resets
> in the chip. We wonder if one reset can be assigned to the dedicated
> reset routing resources and the other one to the normal routing
> resources. We are using Synplify v5.08a, M1.5 and Verilog.
>
> We have looked at the Synplify and M1.5 manuals, and following things
> came out:
>
> 1. In the Xilinx manual "Synthesis and Simulation Design Guide", page
> 4-9, in the first paragraph:
>
> "XC4000 and Spartan devices have a dedicated Global Set/Reset
> (GSR) net that you can use to initialize all CLBs and IOBs. When the
> GSR is asserted, EVERY flip flop in the FPGA is simultaneously preset
> or cleared. You can access the GSR net from the GSR pin on the
> STARTUP block or the GSRIN pin of the STARTBUF (VHDL)."
>
This is correct.

> 2. In the Synplify User Guide book, at the section "Xilinx FPGA Support",
> at the item "Startup Block for XC4000 and XC5200", 3rd paragraph:
>
> "If multiple resets are used in the design, then Synplify will not
> automatically create a startup block in GSR. If you still want one
> of the reset signals to be used for GSR then you will need to
> manually instantiate a STARTUP_GSR module in your design source file."
>
> From 1, I understand that it is impossible to use two resets one of which
> I want to dedicate to GSR routing, because when GSR is asserted, ALL
> the flip flops in XC4000 and Spartan will be resetted, some of which
> actually have their own individual reset signal, which is not using
> GSR routing but normal routing.
>
If you use the dedicated GSR net, then ALL flip-flops will be
reset/preset, regardless of what other reset/presets they have. If I
understand correctly, you have some flip-flops which will be reset/preset by
one input, and some which will be reset/preset by another input but no
flip-flops which will be reset/preset by both. If this is the case, then you
can't use the GSR net at all.

> From 2, I understand that it is possible to use two resets and one
> reset can be asserted to GSR routing and the other one must be used then
> in normal routing. But 2 is correct only for XC4000 devices, since
> the item is "Startup Block for XC4000 and XC5200", there is not the
> word "Spartan" at the header title of the item.
>
I guess that this is a  limitation of Synplicity. (comments from
Synplicity users?). I think what they'te talking about here is the case when
all flip-flops are reset/preset by the GSR net and some flip-flops have an
extra reset/preset condition which will reset/preset them at other times.
It is possible use the startup block in Spartan devices - use the
XC4000/Spartan family library.

> If Xilinx is true, then I conclude that when I want to use more than
> one reset in Spartan or XC4000, then routing will be worse, since
> I mustn't use GSR usage for a correct operation and the resets will
> use normal routing resources. That will make the routing more difficult.
I think this is the case.

> If Synplify is true, then I conclude that when I want to use more
> than one reset in XC4000 and XC5200, and when I want to assign one
> of the two reset signals to the GSR routing, then routing will be
> used efficiently.
>
> Which is correct?
>
> Utku
>
>
In summary, if you use the startup block (either by instantiating it
or inferring it), the GSR net will reset/preset ALL flip-flops. Remember
that the GSR net will reset/preset the flip-flops to their
post-configuration state.

Mark Harvey.

>  _____________________________________________________________
>  http://www.deja.com/
>  * To modify or remove your subscription, go to
>  http://www.deja.com/edit_sub.xp?group=comp.arch.fpga

Sent via Deja.com http://www.deja.com/

Article: 19043
Subject: CIC Filters in FPGA
From: "Mariotto" <mariotto@libero.it>
Date: Thu, 25 Nov 1999 10:57:12 GMT
Links: << >>  << T >>  << A >>
Where I could find information on realizations of CIC filters supposed from
E.B. Hogenauer in FPGA?
Thank you.

Claudio Casagrande

e-mail:mariotto@libero.it


Article: 19044
Subject: async latch implementation in Leonardo
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Thu, 25 Nov 1999 03:05:22 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm wondering how Leonardo syntheses async latches.

process (.......)
if  A=2 then Alatch<='1';
elsif A=5  then Alatch<='0';
end if
end;

Ever if I implement something like this, Xilix alliance say " clock
using non dedicated resources found.... It is not good design praxis."
Now I have looked in RTF viewer from Leonardo. I have not found Alacht
latch!!!!!!!!!!!!!

1.Can anybody explain me, where is my latch
2. Does it in principaly normal design praxis to use level sensitive
latches?

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


Article: 19045
Subject: LOC's RLOC's and Virtex
From: "Gordon Hollingworth" <gsh100@york.ac.uk>
Date: Thu, 25 Nov 1999 12:18:49 -0000
Links: << >>  << T >>  << A >>
Can anybody tell me how it is possible to specify the F or G LUT for the
LUT4 symbol?  Is there anyway of doing it in the Virtex device?


Article: 19046
Subject: Lucent: OR3TP12, Some work arounds that we have found.
From: Edward Wallington <edward.wallington@crsltd.com>
Date: Thu, 25 Nov 1999 12:42:13 -0000
Links: << >>  << T >>  << A >>
Thanks to everyone that has posted in this thread so far.

My reason for my original posting was not to recommend alternative
solutions,
but rather to find out what experience of the Lucent OR3TP12 part other
people have.

We are just putting into production a "visual stimulus generator"
(basically a graphics
card for medical eye research, I won't bore you with the details) -
based around the
Lucent chip on a 32bit PC pci bus, target mode only.

Our system basically works, but we get stability problems in some PC's
(my guess
is that it is chipset dependent, but there could be other factors at
play). This can
appear as lost / corrupted reads or writes.

The workarounds we have found are:

PCM: (this may also be applicable to a problem mentioned in another
to have recently changed their mind about the values to put in the
register that configures the
PLL to operate over a given range of frequencies. The software (9.35) I
think has not incorporated
these changes, so the answer is look up the value in the latest orca3
fpga data sheet, then look up what values
of frequency in the old datasheet give the same value value. Then set
the constraint for the PLL with this
frequency (which in our project was significantly higher). This has
worked for 2 date codes of the OR3TP12.
I only have experience of the PLL mode though.

Fclk: (fifo clocks) we suspect there is a problem if the fifos are
clocked with a signal that is slow (10MHz) w.r.t. the pci bus.
The core seems to get tangled up with a subsequent transaction. You get
clock it quicker!

There also appears to be issues if you leave a dead clock cycle between
requesting the address and requesting the data,
(we have a pipeline stage), you end up with a short data phase. This may
be a timing problem on our part, but has anyone
else found anything similar? One thing lucent don't spell out is that
the signals from the core appear / disappear on FALLING
edges of the fifo clocks (look carefully at the timing diagrams). Our
data was disappearing half a clock before we were registering it!

To sum up; we are desperate to ship some boards soon so any help would
be greatly appreciated. As a sweetener I will email
a copy of our rough 'n ready DOS utility, that uploads a "mcs" file to
the lucent via the pci bus to anyone who can offer some hints :<)

If anyone wants to buy a board (32bit) with a Lucent on it, get in touch
:<)

Ed.

--
Edward Wallington - Chief Hardware Engineer
Cambridge Research Systems Ltd.
Tel: +44 (0)1634 720707 Fax: +44 (0)1634 720719
http://www.crsltd.com


Article: 19047
Subject: Re: VHDL vs. schematic entry
From: rk <stellare@NOSPAM.erols.com>
Date: Thu, 25 Nov 1999 08:01:24 -0500
Links: << >>  << T >>  << A >>
John Larkin wrote:

> Greg,
>
> that statement intrigued me. Around here, we've debated some about the
> 'illegal state' issue. The positions are...
>
> 1. Any state machine should be able to walk its way out of any illegal
> state into a correct sequence

i would mostly agree.  however, for some machines, a periodic reset will
accomplish the same thing with the same out of system lost time and quite
a bit less effort and hardware (e.g., say zero a state machine for each
line read out of an imaging array).  you would lose a direct indication
though.  it depends on the problem and its requirements.  designing a
state machine so that it never gets into trouble is quite a bit harder.

-------------------------------------------------------------

> or
>
> 2. Bull! If something's impossible, you don't need to worry about it.
> If a state machine gets into an impossible state, then the FPGA is
> broken. After all, if software gets into an impossible state (like the
> PC in the middle of a data table or somesuch) then it's crashed.

again, i'll partly agree.  if the fpga is busted, then, well, it's
busted.  trying to design a fault tolerant circuit inside of a single fpga
is not easy (and you can't cover them all, but a lot of them).

on the other hand, the realities of the system may put your state machine
in a bad state.  an esd pulse from someone touching the box for
commercial/lab systems; a dropout on the power bus from building power
dropping  or getting funny (commercial, lightning strike) or the system
power dropping from some sort of event (military, aerospace, use your
imagination); or from cosmic rays or perhaps nuetrons for high altitude
civilian or military avionics or spacecraft electronics can put a state
machine in a bad state.  likely? no.  but not impossible and for certain
system requirements it may have a requirement to not lock up.

anyways,

it's an interesting topic,

have a good day

=================================================

> (sorry about bringing up an even-less relevant point!)
>
> Ideas?

actually, it's a very relevant point and the methods that various
synthesizers deal with this problem and one's attempts to cope with it.

------------------------------------------------------------------------
rk                                 The world of space holds vast promise
stellar engineering, ltd.          for the service of man, and it is a
stellare@erols.com.NOSPAM          world we ahve only begun to explore.
Hi-Rel Digital Systems Design      -- James E. Webb, 1968


Article: 19048
Subject: Re: async latch implementation in Leonardo
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Thu, 25 Nov 1999 05:40:21 -0800
Links: << >>  << T >>  << A >>
I'm now in Leonardo RTL viewer.
I can't believe my eyes.

Do you know what Leonrdo makes from this RS-trigger
Hi make clocked latch!!!!!!!!!  with S -clock signal!!!!!!!!!!!!!! and
R -async reset signal.

library ieee; use ieee.std_logic_1164.all;

entity  LT  is
port (o : out std_logic ;
r : in std_logic ;
s : in std_logic );
end;

architecture  LT  of  LT  is
begin
process (R,S)

begin
if  R='0' then tclr <='0';
else if S='0' then tclr <='1';
end if;
end if;

end process;
end;

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


Article: 19049
Subject: Re: VHDL vs. schematic entry
From: Greg Neff <gregneff@my-deja.com>
Date: Thu, 25 Nov 1999 15:33:20 GMT
Links: << >>  << T >>  << A >>
In article <lrc8OPRknqV34Krqe+dRcbWiqbXz@4ax.com>,
John Larkin <jjlarkin@highlandSnipSniptechnology.com> wrote:

(snip)
>
> that statement intrigued me. Around here, we've debated some about the
> 'illegal state' issue. The positions are...
>
> 1. Any state machine should be able to walk its way out of any illegal
> state into a correct sequence
>
> or
>
> 2. Bull! If something's impossible, you don't need to worry about it.
> If a state machine gets into an impossible state, then the FPGA is
> broken. After all, if software gets into an impossible state (like the
> PC in the middle of a data table or somesuch) then it's crashed.
>
(snip)

I tend to agree with #2, but we do work on mission critical designs for
transportation and aerospace.  These guys aren't happy unless you can
show them that you can recover from the impossible.  They want to see
that the design won't lock up if an illegal state is entered, due to

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Sent via Deja.com http://www.deja.com/