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

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

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

Custom Search

Messages from 19250

Article: 19250
Subject: Re: JTAG on PCI slot
From: "Holger Kleinert" <Holger@hollgi.de>
Date: Wed, 8 Dec 1999 22:04:37 +0100
Links: << >>  << T >>  << A >>
Pete Dudley <padudle@sandia.gov> schrieb in im Newsbeitrag: 384E6E34.77FB@sandia.gov...
> Holger Kleinert wrote:
> >
> > Bernard Esteban <esteban@worldnet.fr> schrieb in im Newsbeitrag: 82iq91$kpp$1@wanadoo.fr...
> > > Hi,
> > >
> > > Where can I find information how works JTAG signals on PC mother board ??,
> > > the goal, is to check if a PCI card with JTAG devices is well connected with
> > > on PCI slot. The JTAG connector is on PCI card.
> >
> > JTAG is an optional feature of the PCI System.
> > The interfacing for this signal on a mainboard is vendor dependent.
> > Also the boundary scan order is vendor dependent.
> > I found no information regarding this manner in the PCI Spec V 2.2.
> >
> > I guess the PCI-JTAG is most used for product verification during factory assembly.
> > --
> > mfg
> > Hollgi
> > http://www.hollgi.de
>
>
> My guess is that the JTAG signals on the PCI connector are never used by
> anyone for testing. JTAG is a very complicated and slow way to test.
Ohh , that doesn't matter if only approx. 100 connections from any JTAG Compliat PCI device to the slot have to be tested
against soldering problems..
I know this takes just a second...
>
> On the other hand the JTAG signals on a PCI card could be very useful
> for programming In System Programmable (ISP) devices.
Good idea :-)

Holger
http://www.hollgi.de



Article: 19251
Subject: Re: constraints between clock domains: can't advance
From: husby@fnal.gov (Don Husby)
Date: Wed, 08 Dec 1999 22:06:24 GMT
Links: << >>  << T >>  << A >>
Apologies to everyone, this message is for the original poster,
Utku Ozcan, only.

Utku:
  I tried replying to your private email using this address:
    Utku Ozcan <ozcan@mimoza.netas.com.tr>

  I got the following error message:

> This report relates to a message you sent with the following header fields:
>
>  Message-id: <4.2.0.58.19991208155226.00a3fd40@popgtw.fnal.gov>
>  Date: Wed, 08 Dec 1999 15:52:53 -0600
>  From: Don Husby <husby@fnal.gov>
>  To: Utku Ozcan <ozcan@mimoza.netas.com.tr>
>  Subject: Re: Problems with routing Virtex device
>
> Your message cannot be delivered to the following recipients:
>
>  Recipient address: ozcan@mimoza.netas.com.tr
>  Reason: Illegal host/domain name found



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 19252
Subject: Re: constraints between clock domains: can't advance
From: bob@nospam.thanks (Bob Perlman)
Date: Wed, 08 Dec 1999 22:07:18 GMT
Links: << >>  << T >>  << A >>
On Wed, 08 Dec 1999 21:47:25 +0200, Utku Ozcan
<ozcan@mimoza.netas.com.tr> wrote:

>Design Entry: Verilog
>Synthesizer: Synplify v5.21
>P&R: Design Manager M1.5 patched
>Technology: XC4044XLA
>
>We have two clock domains, 25 MHz and 6 MHz, and 25 MHz is derived
>internally. Two separate FSM's in different clock domains communicate
>to each other. Since implementation is quite fast, we directly perform
>postroute simulations.
>
>The problem is, that FSM's can't talk to each other in lab. FSM's are
>alike, they have 1-bit states, at every execution the states are expected
>to toggle, 0-1-0-1..., as we have seen at postroute simulations.

> [other stuff deleted]

Can you post your Verilog?

Bob Perlman

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 19253
Subject: press release
From: "OC team" <administration@opencores.org>
Date: Wed, 8 Dec 1999 23:49:34 +0100
Links: << >>  << T >>  << A >>
SynaptiCAD supports OPENCORES Initiative with Free HDL Simulators and Test
Bench Generators. Press release is available online at

http://www.opencores.org/press/press_release_9dec1999.shtml

regards,

OPENCORES.ORG team



Article: 19254
Subject: Re: JTAG on PCI slot
From: murray@pa.dec.com (Hal Murray)
Date: 9 Dec 1999 00:29:53 GMT
Links: << >>  << T >>  << A >>

> On the other hand the JTAG signals on a PCI card could be very useful
> for programming In System Programmable (ISP) devices.

I can't figure out how to take advantage of that - at least
in the general case.

How are you going to decide which bits to load?  Remember, if
this idea takes off everybody else will use it too.  So you have
to be able to figure out what type of card is plugged into that slot
before you have loaded the logic.  If you could read the PCI device
ID register then the card would be working, at least somewhat,
so you are just loading some non-PCI logic and you can use the
PCI connection to do that.

Am I missing something?

I assume it would work fine is a special case where you knew
which cards were in which slots.

-- 
These are my opinions, not necessarily my employers.
Article: 19255
Subject: Re: TIme Delay 1us-100ms
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 08 Dec 1999 18:08:44 -0800
Links: << >>  << T >>  << A >>
Well, you really need to divide by max 800,000 with a 20-bit counter.
The easiest way to divide by selectable numbers is to implement a synchronously
loadable 20-bit down counter, which takes  11 CLBs in XC4000.
You then use the overflow signal to signal the time-out. The binary load value
determines the delay. Since you start with 8 MHz and want a min resolution of 1
microsecond, you load zeros into the three LSBs. If you prefer an up-counter, then
you must load the complement of the desired time.
The design is really trivial, since it uses the dedicated carry logic in XC4000.

Peter Alfke, Xilinx Applications
=======================
muzo wrote:

> Moussa Ba wrote:
> > Good Day,
> > What is the best to way to implement a Delay ranging from 1us to 100ms,
> > I am synthesizing some verilog code for use with a xilinx xs4005xl.
> > Could you please direct me to the best code construct for implementing
> > such a delay.  The clock in my design is 8MHz and I am using Xilinx
> > Foundation 1.5 software.
> >
> > Thank you in advance
>
> I will take the trivial interpretation of this question and try to
> answer it.
> If you need a single programmable delay you can use a single
> synchronous counter and reset it to overflow at different numbers to
> implement the delay. 8 MHz has a 125 ns period so you need a counter
> from 8 to 10e5 which a 17 bit counter can do. You can register the
> signal you want to delay everytime the counter overflows. If you want
> multiple delays of fixed size, you can do a ripple counter (you don't
> want many 17 bit counters because of size) and divide 8 MHz into
> smaller speeds. The you can pick the outputs of some of registers in
> the ripple counter to drive much smaller synchronous counters the size
> of which depends on the precision you need in the delay.
>
> Hope this helps.
> muzo
>
> Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)

Article: 19256
Subject: Re: JTAG on PCI slot
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 9 Dec 1999 03:38:19 GMT
Links: << >>  << T >>  << A >>
In article <82mt61$sld@src-news.pa.dec.com>,
Hal Murray <murray@pa.dec.com> wrote:

>How are you going to decide which bits to load?  Remember, if
>this idea takes off everybody else will use it too.  So you have
>to be able to figure out what type of card is plugged into that slot
>before you have loaded the logic.  If you could read the PCI device
>ID register then the card would be working, at least somewhat,
>so you are just loading some non-PCI logic and you can use the
>PCI connection to do that.

>Am I missing something?

>I assume it would work fine is a special case where you knew
>which cards were in which slots.

Assume that you only ever add or move cards of one type for each reboot. 
The device driver knows which slot no. the card is supposed to be in (the
first guess is slot 0).  If the card does not appear to be in that slot, the
driver uploads to each slot which appears blank until it finds the card, and
records the slot no. where it finds the card.  This reduces configuration
time too, since after the card is installed, the driver will try only the
correct slot.

Of course there will be havoc if there are multiple people using this scheme
and the user decides to upgrade his motherboard (in which case cards of
different types have to be configured).

A simple standard we should try to agree on is a two-stage FPGA
configuration process.  For stage one we upload a tentative configuration
which keeps all outputs tri-state except for a few which communicate with a
tiny serial flash prom which contains a copy of the card id.  Once the card
is verified, stage two is commenced: the FPGA is reconfigured with the
application.  When a driver is looking for its cards, it is permitted to
reconfigure cards which are in stage one.  Perhaps a good place for this
prom is the M1, M2 and M3 lines which can double-up as I/O (at least for
Xilinx FPGAs).

To configure the addresses after the normal PCI configuration, just subtract
the amount your card needs from the lowest addressed PCI card in the system
(ignoring anything which appears below the end of RAM), and use it.  Anyway
this works for the special, but very important case of Windows-95/NT/Linux
on a PC.

I actually don't use JTAG pins (I don't know how or even if they work
through PC PCI controller chips).  Instead I have a little discrete-logic
circuit which latches some low order configuration write address bits (which
get through even if there is no devsel response) when the configuration
write is to a high and otherwise unused area.  The output of this latch
feeds CCLK, DIN and NPROG.  This circuit is resistor isolated from the PCI
bus so that it does not add too much extra load.

Unusual FPGA configuration is an amusing subject.  I know someone who made a
macintosh video card which was composed of an XC2064-50 (the first, smallest
and slowest fpga!), 4 DRAM chips and a crystal.  Period.  Now this was for
the original macs which didn't have add-on slots- the card was designed with
a "Killy-clip" which would clip onto the 68000 microprocessor pins.  I don't
know which CPU signals they used for configuration (parallel mode I guess
and extra address lines for chip select), but somehow they made this thing
work and sold a bunch of them (including the high res. 19" monitor which
went along with it).

Another configuration method which I find to be convenient is to use a
74LS123 dual one-shot (or a couple of 555s) for a clock separator for RS-232
serial.  The start bit triggers one one-shot.  When that times out, the
second is triggered which generates the CCLK pulse right in the middle of a
9600 baud frame.  The software sends FFs and 00s over the serial line to
configure the FPGA.  I modified a Medicaid point of sale device (basically a
credit card reader) by adding one fpga, a crystal, the 'LS123 some
transistors and a DB9 connector so that I could read the vacuum fluorescent
display and simulate keypresses with a separate PC.  The purpose was to
automate the eligibility verifcation process for a methadone clinic (they
have to verify each patient every day and this was the only way to do it- it
was actually one person's entire job to do this).  The hard part was that
the EDS P.O.S. device had two circuit boards sandwiched together (and which
you want to separate when you dissassemble the thing). One had the battery
and the other had the RAM which contained the program for the device. 
Anyway this was easier than hacking the protocol.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 19257
Subject: Lattice ispLSI Security
From: bureauc@hotmail.com (Jeff Smith)
Date: Thu, 09 Dec 1999 04:14:05 GMT
Links: << >>  << T >>  << A >>
I am just starting to look at incorporating the Lattice reprogrammable
parts like the ispLSI1016E or maybe some of the bigger parts, but I am
wondering just how secure they are, once the fuse is blown. Since even
with a blown security fuse, they can be erased and reused....is it
really all that secure?  The programs they provide (e.g. the Daisy
Chain Download program) can't read a secured part, but is this a case
of the part being impossible to read, physically, or is someone going
to be able to read it with relative ease, given proper knowledge and
tools?  Would I be ahead using a different type of part for better
security?

TIA,

Jeff Smith
Article: 19258
Subject: JTAG programming problem with multiple Altera MAX7000A devices
From: Andrew Reddig <andyr@tekmicro.com>
Date: Thu, 09 Dec 1999 00:00:46 -0500
Links: << >>  << T >>  << A >>
Subject tells the story.  We have started to have a lot of problems
lately programming Altera devices through JTAG.  We have both a
"BitBlaster" (serial interface to JTAG port) and a ByteBlasterMV
(parallel port interface to JTAG).  We have had a wide range of problems
on many different designs.

The common thread is that the device fails to program and MAX-Plus
either reports that the device is unknown, not installed, JTAG chain is
bad, or else does an examine/program and then fails with verify errors. 
In the latter case, we can often get exactly the same # of verify errors
each time.

This happens with two different computers, a couple of different
versions of MAX-Plus, and both the BitBlaster and the ByteBlasterMV.  It
also happens with both single EPLD systems and cards that have five
devices in a chain.

The only common thread is that the problem seemed to start when we
started using MAX7000A's, although it sometimes happens with 7000S
devices as well.

We've checked pinouts, clocks, signals; all look fine.  We've tried
using the ByteBlasterMV with both 3.3V and 5V, no difference.  We've
buzzed out the cables, tried terminating TCK, and nothing works.  But,
every now and then, you can press "Program" 55 times and get it to work
on the 55th.  Sometimes, you can program all 5 chips in a chain a few
times without complaint, then it starts failing again.

Anybody seen this kind of thing?  Any ideas?  We're pulling our hair
out.

Thanks for any suggestions.

-- 
Andrew Reddig                            andyr@tekmicro.com
TEK Microsystems, Incorporated                 781.270.0808
One North Avenue                           Fax 781.270.0813
Burlington, MA  01803           Web http://www.tekmicro.com
Article: 19259
Subject: Re: press release
From: please@dont.mail.me.com
Date: Thu, 09 Dec 1999 09:32:46 GMT
Links: << >>  << T >>  << A >>
On Wed, 8 Dec 1999 23:49:34 +0100, "OC team"
<administration@opencores.org> wrote:

>SynaptiCAD supports OPENCORES Initiative with Free HDL Simulators and Test
>Bench Generators. Press release is available online at
>
>http://www.opencores.org/press/press_release_9dec1999.shtml
>
>regards,
>
>OPENCORES.ORG team

Perhaps Dan Notestein, President of SynaptiCAD, should have told it
like it is. In case he needs some help, I've given him some clues
below.

Dan thinks:

"Anyone who's desperate enough to get free IP off the web is going to
have to do a *hell* of a lot of verification. So much verification, in
fact, that they might as well just have written the code in the first
place. However, since we write Verification Tools, this is a Massive
Market Opportunity for us. Hey, why don't we ship free tools to
developers? Just imagine the phone calls to Opencores 'support':

a) 'This core doesn't work'.
b) 'Well, I don't know who wrote it, but they used SynaptiCAD, so it
must work'.
a) 'I just told you it doesn't work'.
b) 'I think you're wrong. Hey, why don't you buy SynaptiCAD to check
it out?'.

"But, on the other hand, this move might piss off Engineers who
actually have to work for a living. They might even get so annoyed
that they don't buy our tools. They might even point out to other
engineers that waveform-based verification is next to useless. But
hey, what the hell? It's worth a go."


Article: 19260
Subject: Re: constraints between clock domains: can't advance
From: jim granville <jim.granville@paradise.net.nz>
Date: Thu, 09 Dec 1999 22:57:27 +1300
Links: << >>  << T >>  << A >>
Utku Ozcan wrote:
> 
<snip>
> To overcome this problem, we have inserted FF's between clock domains,
> for a possibility of metastability etc. Signals between clock domains
> are constrained with acceptable TIMESPEC commands. But no advance.
> 
> I have read several mails posted to newsgroup so far, the opinions
> are centered to:
> 
> - incapability of resetting to complete system
> - metastability condition right after reset deassertion

There is also an effect, often mis-stated as metastability, that is
really an aperture time effect.
This occurs when you have MULTIPLE registers able to change, on a single
clock edge.
Or, put another way, if the ASYNC term appears in more than ONE SYNC
register
equation at a time.

If this happens, and you expect  00 -> 11, then you CAN get both 
01 and 10 as illegal states, purely as a result of jitter in the Tsu/Th
of the two FFs. This can be >> metastability time, and can be hundreds
of pS. 

Eliminating it can be tricky, and normally costs some latency.

Jim G.

-- 
======= 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: 19261
Subject: Re: constraints between clock domains: can't advance
From: Bonio Lopez <bonio.lopezNOboSPAM@gmx.ch.invalid>
Date: Thu, 09 Dec 1999 02:59:51 -0800
Links: << >>  << T >>  << A >>
Hi,
I think you have to provide that inputs of the state machines (SM)
never change at the time of clock transitions. If it is happens the SM
can work incorrectly (for example go to " if others" state ).
You could for ex. latch the inputs with other clock transition as SM
work
Hope it helps,
Bonio



* 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: 19262
Subject: Re: JTAG programming problem with multiple Altera MAX7000A devices
From: Dan Rymarz <m261981@boeing.com>
Date: Thu, 9 Dec 1999 13:27:09 GMT
Links: << >>  << T >>  << A >>
I have similar problems with a 7256 and a 10k30, except that the
7256 programs pretty good and the 10k30 is extremely flaky.  The
funny thing is both are on the same chain.

Andrew Reddig wrote:
> 
> Subject tells the story.  We have started to have a lot of problems
> lately programming Altera devices through JTAG.  We have both a
> "BitBlaster" (serial interface to JTAG port) and a ByteBlasterMV
> (parallel port interface to JTAG).  We have had a wide range of problems
> on many different designs.
> 
> The common thread is that the device fails to program and MAX-Plus
> either reports that the device is unknown, not installed, JTAG chain is
> bad, or else does an examine/program and then fails with verify errors.
> In the latter case, we can often get exactly the same # of verify errors
> each time.
> 
> This happens with two different computers, a couple of different
> versions of MAX-Plus, and both the BitBlaster and the ByteBlasterMV.  It
> also happens with both single EPLD systems and cards that have five
> devices in a chain.
> 
> The only common thread is that the problem seemed to start when we
> started using MAX7000A's, although it sometimes happens with 7000S
> devices as well.
> 
> We've checked pinouts, clocks, signals; all look fine.  We've tried
> using the ByteBlasterMV with both 3.3V and 5V, no difference.  We've
> buzzed out the cables, tried terminating TCK, and nothing works.  But,
> every now and then, you can press "Program" 55 times and get it to work
> on the 55th.  Sometimes, you can program all 5 chips in a chain a few
> times without complaint, then it starts failing again.
> 
> Anybody seen this kind of thing?  Any ideas?  We're pulling our hair
> out.
> 
> Thanks for any suggestions.
> 
> --
> Andrew Reddig                            andyr@tekmicro.com
> TEK Microsystems, Incorporated                 781.270.0808
> One North Avenue                           Fax 781.270.0813
> Burlington, MA  01803           Web http://www.tekmicro.com
Article: 19263
Subject: Passing attributes from VHDL with FPGA Express for Xilinx
From: Matthieu Liger <ligerm@esiee.fr>
Date: Thu, 09 Dec 1999 15:01:16 +0100
Links: << >>  << T >>  << A >>
Hi everyone,

I am looking for a way to constrain things like pin locations in
syntesis for Xilinx
with FPGA express. I know it is possible to do this with the "constraint
editor", but
I'd like to do it by passing attributes from my VHDL source code.

I tried tings like:
..
port(
data: std_logic_vector(7 downto 0);
...

attribute LOC: string;
attribute LOC of data: signal is "P39,P37,P10,P11,P12,P13,P14,P15";

But these directives are not written in the .xnf netlis, nor in the .ucf
file

I looked for instructions in the documentation....but I found nothing...

Can anybody help me ??
Thanks

-- 
Matthieu Liger, Groupe ESIEE-Paris
Currently looking for an internship
in microelectronics, see 
http://www.esiee.fr/~ligerm
Article: 19264
Subject: Re: JTAG on PCI slot
From: Ray Andraka <randraka@ids.net>
Date: Thu, 09 Dec 1999 09:33:34 -0500
Links: << >>  << T >>  << A >>


Joseph H Allen wrote:

> A simple standard we should try to agree on is a two-stage FPGA
> configuration process.  For stage one we upload a tentative configuration
> which keeps all outputs tri-state except for a few which communicate with a
> tiny serial flash prom which contains a copy of the card id.  Once the card
> is verified, stage two is commenced: the FPGA is reconfigured with the
> application.  When a driver is looking for its cards, it is permitted to
> reconfigure cards which are in stage one.  Perhaps a good place for this
> prom is the M1, M2 and M3 lines which can double-up as I/O (at least for
> Xilinx FPGAs).

This is only good if everyone uses the same FPGA.  Different devices have different
configuration bit streams, even if the pin outs are the same.  A better solution
would be to use a separate, perhaps JTAG compliant, ID rom that could be read
before the FPGA was configured.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19265
Subject: Re: hobbyist friendly pld?
From: Nigel Orr <news@river-view_dot_freeserve.co.uk>
Date: Thu, 09 Dec 1999 14:47:09 GMT
Links: << >>  << T >>  << A >>
On Mon, 06 Dec 1999 08:33:58 GMT, Leon Heller
<leon_heller@hotmail.com> wrote:

>Get the Xilinx starter kit. It comes with a JTAG programmer, a little
>CPLD evaluation board, and software that supports the CPLDs and the
>Spartan series of FPGAs, as well as the older devices. It's about $100.

Is that the same one as:
http://www.microcall.memec.com/xilinx/promo.htm - £60 in the UK?

I'm considering it as an FPGA starter kit- anyone had any experience
with it?  Any time or feature limitations I should be aware of?  I
know it doesn't have VHDL./Verilog.

If that isn't it, do you have a UK source for the Xilinx one you
mentioned?

Nigel
Article: 19266
Subject: Re: Passing attributes from VHDL with FPGA Express for Xilinx
From: Ray Andraka <randraka@ids.net>
Date: Thu, 09 Dec 1999 09:51:24 -0500
Links: << >>  << T >>  << A >>
I think you'll need to instantiate primitives for the IOBs and put the
attributes on the instance labels, as shown in the snippet below.  Also,
FPGA express previously did not pass user attributes to the netlist (about
this time last year).  I understand the newer release does, but I haven't
tried it again.

entity foo is
port(
pad
);
end foo;
architecture pad_inst of foo is
component  IOBUF
   port(
      O                              : out   STD_ULOGIC;
      IO                             : inout STD_ULOGIC;
      I                              : in    STD_ULOGIC;
      T                              : in    STD_ULOGIC);
end component;
attribute LOC: string;
attribute LOC   of U1 : label is "P39";
begin

U1:IOBUF port map(
    O=> int_out,
    IO=> pad,
    I=> int in,
    T => int_ts);
end pad_inst


Matthieu Liger wrote:

> Hi everyone,
>
> I am looking for a way to constrain things like pin locations in
> syntesis for Xilinx
> with FPGA express. I know it is possible to do this with the "constraint
> editor", but
> I'd like to do it by passing attributes from my VHDL source code.
>
> I tried tings like:
> ..
> port(
> data: std_logic_vector(7 downto 0);
> ...
>
> attribute LOC: string;
> attribute LOC of data: signal is "P39,P37,P10,P11,P12,P13,P14,P15";
>
> But these directives are not written in the .xnf netlis, nor in the .ucf
> file
>
> I looked for instructions in the documentation....but I found nothing...
>
> Can anybody help me ??
> Thanks
>
> --
> Matthieu Liger, Groupe ESIEE-Paris
> Currently looking for an internship
> in microelectronics, see
> http://www.esiee.fr/~ligerm



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19267
Subject: Vantis MACH ISP
From: Rich Walker <rw@shadow.org.uk>
Date: Thu, 09 Dec 1999 15:21:16 +0000
Links: << >>  << T >>  << A >>
I've just managed to cook a MACH4 ISP chip, I think. As a result of the
cooking process, the JTAG ID it returns is all-1's. 

Has anyone else seen this from cooking MACH4 chips? Or am I likely
to have cooked the parallel port programming adapter?


cheers,Rich.


-- 
Rich Walker: rw@shadow.org.uk (Shadow Robot Project)
http://www.shadow.org.uk        251 Liverpool Road
+44(0)171 700 2487                London  N1 1LX
"Sometimes after an electrical storm I see in 5 dimensions"
  -- Cornfed Pig,  Duckman.
Article: 19268
Subject: Re: JTAG on PCI slot
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 9 Dec 1999 15:52:56 GMT
Links: << >>  << T >>  << A >>
In article <384FBDBE.670FB420@ids.net>, Ray Andraka  <randraka@ids.net> wrote:

>Joseph H Allen wrote:

>> A simple standard we should try to agree on is a two-stage FPGA
>> configuration process.  For stage one we upload a tentative configuration
>> which keeps all outputs tri-state except for a few which communicate with a
>> tiny serial flash prom which contains a copy of the card id.  Once the card
>> is verified, stage two is commenced: the FPGA is reconfigured with the
>> application.  When a driver is looking for its cards, it is permitted to
>> reconfigure cards which are in stage one.  Perhaps a good place for this
>> prom is the M1, M2 and M3 lines which can double-up as I/O (at least for
>> Xilinx FPGAs).

>This is only good if everyone uses the same FPGA.  Different devices have
>different configuration bit streams, even if the pin outs are the same.

It would be fine.  If you upload an incorrect bit-stream the fpga ignores it
and you won't be able to read the prom.  The driver would then just move on
to the next board.  The board's own device driver has to configure it- not
the BIOS.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 19269
Subject: EEPROM for spartan xl series FPGA?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Thu, 09 Dec 1999 11:11:50 -0500
Links: << >>  << T >>  << A >>
Can someone dirrect me to a specific ap note on how to connect a
configuration prom to a Spartan XCS05XL series FPGA.  I would prefer to
avoid OTP devices.  So far I have found information on the XC17S05.
This is, of course, a OTP device.  I have only one FPGA and one EEPROM.
Based on that info I think that this is correct:

FPGA (XCS05XL)                             PROM
DIN                           <-----                DATA
CCLK                         ----->               CLK
DONE                        ----->               CE         (Is this
direction correct?)
INIT_bar                   ----->                OE/reset_bar

my guess for the other signals

FPGA INPUTS                                  OTHER SIGNALS
M0                             -----                 open circuit(??)
M1                             -----                 open circuit(??)
PWR_DOWN_bar     -----                 held low until power is stable

The data sheet on the Spartan configuration prom shows a reset input on
the FPGA but I can't find that in the data sheet (except for the one
generated in my design) so I assume that that is really the PWR_DOWN_bar
signal.  In my case the power could come up comparitively slowly.  (I am
note certain how long, but 50 mSec is only 3 full cycles at 60 Hz.)   I
note that the ap notes talk about power supply rise time (1 to 3 volts)
being less than 50 mSec.  Is there a _simple_ hardware work around for
this problem such as holding some pin(s) low?  I would rather not switch
the FPGA power supply.

Obviously the In-Circuit-Programable device would use some more signals
on the configuration PROM.  What are they and how do I connect them?
Again specific examples would be greatly appreciated.  I would rather
get this correct the first time.  While I am at it what ISP device is
appropriate for the XCS05XL Spartan FPGA?  As a second alternative a
reprogramable but not ISP device would be a second choice.  Thanks so
much for your patience and help.

Article: 19270
Subject: Re: CAN testing - Any CANbus cores out there?
From: "F.Rodriguez" <prodrig@disca.upv.es>
Date: Thu, 09 Dec 1999 18:36:39 +0100
Links: << >>  << T >>  << A >>
This is original message from the CAN LIST

-- CANLIST message --

The European Space Agency has released the VHDL source code of the
prototype CAN controller core. Information can be found at the following
address:

ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/can.htm

The core is now in its Alpha 3.0 version, that means non extensively tested
and not passed the official
Bosch testbench.
Please note that the simulation libraries for Modeltech and the
pre-synthetized version for ACTEL
FPGA are free, while to been able to extract the VHDL source files you need a
password. If you want
to join the development effort and receive the password to extract the source
files please print the
Non Disclosure Agreement that you find on the web page and send it signed to
the indicated address.

F. Mazzaglia
ESA/ESTEC
Keeplerlaan 1
2200 AG, Noordwijk
The Netherlands

The NDA is meant to limit the distribution of the source code before it
become an official release.

The usage of the core is not restricted in any way by ESA, and the core will
remain always of public domain.

Please note that to produce a CAN node chip you have to request a license to
Bosch for copyright fee.


Luca Stagnaro  (lstagnar@estec.esa.nl)
Spacecraft Control and Data Systems Division
Automation and Informatics Department
European Space Agency


--
To unsubscribe use canlist-request@vector-informatik.de
Archive: ftp://ftp.vector-informatik.de/pub/archive/
Problems to canlist-owner@vector-informatik.de
Home at Vector Informatik GmbH, Germany (www.vector-informatik.de)

-- CANLIST message --

Hope it helps. I can not tested the model yet

Joseph Hlebasko wrote:

> I don't have the URL with me, but on the CAN mailing list a notice was
> published about a "public domain" CAN core.  The organization was
> European Space Agency (ESA).  The project name was "HuriCANe"
> and was implemented with the purpose of studying the CAN controller.
> I think if you do a search for ESA & Huricane you may find it.
>
> Joseph Hlebasko
>
> Jonathan Bromley <jonathan@oxfordbromley.u-net.com> wrote in message
> news:3846DC36.F45F08DA@oxfordbromley.u-net.com...
> > "Raymond E. Rogers" wrote:
> > > > >   I am organizing a CAN-2.0B testing procedure.
> > <snip my suggestion>
> > > This is certainly feasable and has some advantages
> > <snip>
> > >  OTOH, it
> > > is not as general and synchronization with the MAC layer would have to
> > > be resolved.
> >
> > Yes indeed. - hence my comment about fooling the Rx.
> >
> > It occurs to me to ask whether anyone out there has a
> > synthesisable VHDL core for a CAN controller.  It clearly
> > wouldn't be cost competitive with commodity CAN parts
> > for production, but it sure as hell would make this kind
> > of diagnostic and special-purpose stuff far easier if you
> > had a working controller core to start from that you could
> > modify in an arbitrary way.
> >
> > I would be **very** interested in getting involved in
> > any public-domain effort to realise this goal, as I
> > have upcoming projects for which it would be rather
> > useful.
> >
> > I've posted this also to comp.arch.fpga and comp.lang.vhdl
> > (from sci.electronics.design) in the hope of exciting some
> > interest.
> >
> > Jonathan Bromley



Article: 19271
Subject: Re: backup fifo's(2)
From: Eric Crabill <crabill@xilinx.com>
Date: Thu, 09 Dec 1999 11:13:38 -0800
Links: << >>  << T >>  << A >>
Hi again,

It sounds daunting but it is not hard.  You only need a bi-directional
counter for the read pointer, and you design the full/empty logic to
make the FIFO appear a little "smaller" than you normally would.

For example, if you used SelectRAM in any Xilinx device, you could
create a 14-deep FIFO with a 2-entry back up buffer (so to speak)
by designing the flags as if it were really a 14-deep FIFO.

You would never corrupt the data in the FIFO, even if you have to
back up.  Obviously, you can build larger FIFOs if you require using
additional SelectRAM, or if you need a really big FIFO, you can use
a Virtex device and use the BlockRAM.

As you said, there are simpler alternatives depending on what you are
trying to do.  We are trying to support the broadest range of applications
with our product, and have to account for cases where customers cannot
flush their FIFO.

Thanks,
Eric Crabill

Bruce Nepple wrote:

> A backup fifo gets a little messy when you start dealing with full/empty
> issues.  Little side effects that make things messy.
>
> Actually, all you really need to do is to start another transaction on that
> channel to flush the holding register.
> That would be simpler than (in my case) 3 updown counters and messy logic.

Article: 19272
Subject: Synopsys backannotation
From: Walter Soto Encinas Junior <soto@icmc.sc.usp.br>
Date: Thu, 09 Dec 1999 19:49:24 -0200
Links: << >>  << T >>  << A >>
Hi

        This is a question from a recent Synopsys user. I did a small design
to XC6200 using structural VHDL. I have the VITAL compatible library with
XC6200 primitives (AND, OR, and so on). 

        I analyzed this design for simulation.  The high level (behavioral)
simulation works well.  But I can't backannotate the design with the timing
parameters generated by the placer/router tool, for accurate gate-level
simulation.  These parameters are in SDF format, and looking into the file,
it makes sense. Look: 

(CELL
        (CELLTYPE "AND2B1")
        (INSTANCE COUNT_COL/COUNT_0_INI_1_C_MUX)
        (DELAY
                (ABSOLUTE
                        (PORT I0 (9.476:9.476:9.476) (8.143:8.143:8.143))
                        (IOPATH I0 O (0:0:0) (0:0:0))
                        (PORT I1 (3.040:3.040:3.040) (3.575:3.575:3.575))
                        (IOPATH I1 O (0:0:0) (0:0:0))
        ...

        When I read the design the messages are: 

# vhdlsim -fi_all -sdf_typ -sdf_top /tb_addr/c_addr -sdf addr.sdf CFG_TB_ADDR

**Error: vhdlsim,259: 
    (SDF File: addr.sdf Line: 20) instance
    /TB_ADDR/C_ADDR/COUNT_COL/COUNT_0_INI_1_C_MUX not found.

... and a lot of messages about other instances

        Looking into the design tree, using vhdlsim, I found the path to the
cell shown above. 

# pwd
/TB_ADDR/C_ADDR/COUNT_COL/COUNT(0)/INI/C_MUX
# ls
TIMINGCHECKSON  MSGON           TIPD_I1         I1
VITALBEHAVIOR
INSTANCEPATH    TPD_I0_O        TIPD_I0         I0              I1_IPD
XON             TPD_I1_O        O               WIREDELAY       I0_IPD

        I suppose there is a problem naming the instances. My placer/router
is the XACT6000 and there is no option to control the generation of instance
names in SDF file. Is there some config in Synopsys analyzer to make the
names of instances compatible with the names of SDF? Or this problem needs
another solution ?

        Sorry for the long posting. But it is very, very important! Thanks in
advance.

-- 

|                                       Walter Soto Encinas Jr          |
|                                            PhD  Student               |
|                                             IFSC / USP                |
|                                               Brazil                  |
Article: 19273
Subject: Re: Synopsys backannotation
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 9 Dec 1999 14:57:32 -0700
Links: << >>  << T >>  << A >>
Walter Soto Encinas Junior wrote in message
<385023E4.722A4379@icmc.sc.usp.br>...
>Hi
>
>        This is a question from a recent Synopsys user. I did a small
design
>to XC6200 using structural VHDL. I have the VITAL compatible library with
>XC6200 primitives (AND, OR, and so on).
>
>        I analyzed this design for simulation.  The high level (behavioral)
>simulation works well.  But I can't backannotate the design with the timing
>parameters generated by the placer/router tool, for accurate gate-level
>simulation.  These parameters are in SDF format, and looking into the file,
>it makes sense. Look:
>
># vhdlsim -fi_all -sdf_typ -sdf_top /tb_addr/c_addr -sdf addr.sdf
CFG_TB_ADDR
>
>**Error: vhdlsim,259:
>    (SDF File: addr.sdf Line: 20) instance
>    /TB_ADDR/C_ADDR/COUNT_COL/COUNT_0_INI_1_C_MUX not found.
>
>... and a lot of messages about other instances
>
>        Looking into the design tree, using vhdlsim, I found the path to
the
>cell shown above.
>
># pwd
>/TB_ADDR/C_ADDR/COUNT_COL/COUNT(0)/INI/C_MUX
># ls
>TIMINGCHECKSON  MSGON           TIPD_I1         I1
>VITALBEHAVIOR
>INSTANCEPATH    TPD_I0_O        TIPD_I0         I0              I1_IPD
>XON             TPD_I1_O        O               WIREDELAY       I0_IPD
>
>        I suppose there is a problem naming the instances. My placer/router
>is the XACT6000 and there is no option to control the generation of
instance
>names in SDF file. Is there some config in Synopsys analyzer to make the
>names of instances compatible with the names of SDF? Or this problem needs
>another solution ?

Have you compiled the Xilinx simulation libraries?

-- a
-----------------------------------------
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.



Article: 19274
Subject: Re: Is there two-read one-write asynchronous SRAM in FPGA?
From: Ray Andraka <randraka@ids.net>
Date: Thu, 09 Dec 1999 17:06:01 -0500
Links: << >>  << T >>  << A >>
BZZZZT.  Wrong, not if you want an independent read address.  If you use a single
ported RAM for the second, it's read address is the same as the common write
address, which you already have on the first instance.

John L. Smith wrote:

> Jan Gray wrote:
> >
> [ stuff about multiport SRAMS in FPGAs, concentrating on 3-port RRW ]
> >
> > * 2 2-port SRAMs and do the two RR accessses and the W access in one cycle.
>
> A 25% more area efficient implementation would use 1 2-port and 1
> 1-port.
>
> - John
>
>   ------------------------------------------------------------------------
>
>   John L. Smith <jsmith@visicom.com>
>   Principal Engineer
>   Visicom Imaging Products
>
>   John L. Smith
>   Principal Engineer        <jsmith@visicom.com>
>   Visicom Imaging Products  HTML Mail
>   10052 Mesa Ridge Court    Work: 858-320-4102
>   San Diego                 Fax: 858-??????
>   CA                        Netscape Conference Address
>   92121                     Netscape Conference DLS Server
>   USA
>   http://www.visicom.com/products/Vigra/index.html
>   Additional Information:
>   Last Name     Smith
>   First Name    John L.
>   Version       2.1



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka




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

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

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

Custom Search