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 May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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 22625

Article: 22625
Subject: Re: Future of FPGAs?
From: Victor the Cleaner <jonathan@the-gimp.canuck.com>
Date: 15 May 2000 01:42:20 GMT
Links: << >>  << T >>  << A >>
Peter <z80@ds2.com> wrote:

:>As NRE charges go
:>through the roof for high-density ASICs, FPGAs will continue to severely
:>erode all but the highest-volume ASIC sockets.

: Unless you want low power, in which case an ASIC can give you a 10x +
: advantage in dynamic Icc over an FPGA.

Granted.

:>: FPGAs will be used mainly for prototyping and educational environment.
:>

: Not such a good example, because everything they sell is very high
: priced, so they can afford it.

True, but that has nothing to do with the question, does it?

Jonathan


Article: 22626
Subject: Re: Configuration process %-(
From: fliptron@netcom.com (Philip Freidin)
Date: 15 May 2000 02:40:43 GMT
Links: << >>  << T >>  << A >>
Hi Sebastien,
Time for the next installment on this thread, but first,
I would like to agree with Catalin Baetoniu, who wrote:

>I wouldn't worry about the configuration before solving the LDC and DONE
>signal level problem. Are all your ground pins connected? What is the
>voltage level on these ground pins? What is your reference point when you
>make these measurements? If you find more than 1V between LDC and an FPGA
>ground pin something is definitely wrong. Maybe you have a conflict on
>LDC with another signal that is high. Solve this problem first. Then check
>CCLK for ringing, double clock edges, etc.

In your most recent message, you said that both DONE and INIT whel low
were at 1V. The only thing that makes sense is either the ground pins are
not all connected, or you have REALL low values for their pullup
resistors. I typically use 4700 ohms for the pullups. You must check the
voltage on ALL your ground pins and make sure they are at or very near
ground potential.

In article <39140319.4F0B81E3@utc.fr>,
Sebastien Favard (Gordh) <Sebastien.Favard@utc.fr> wrote:
>Philip,
>
>Thanks really for all you help and your very explicit post.

Ok

>Firstly, when you explain that the Program/ pull down, it's naturally me that
>must pull down this line ?

You must pull it low, then take it back high.

I couldn't find how long it needs to be low in the data sheet, but I
would recommend greater than 5 uS.

>Next the Init/ line pull up, so drive by the FPGA, yes ?

Not quite. The INIT pin should have a pullup resistor connected to it all
the time. I use 4.7K ohms. The FPGA responds to the program signal going
from high to low by starting to do the internal clearing. If it is low for
a long time it will just keep doing the clearing over and over. When you
take program high, it will do the clearing one more time. All during this
time, INIT will be driven low by the FPGA. After program has gone high,
and the clearing process has completed, the FPGA stops driving the INIT
pin low, and your external pullup resistor will pull the INIT line high.
During all this time the CCLK signal must not be running. Typically you
set it high. After INIT goes high and you wait at least 6 uS, you set the
first data bit (a '1') , and the CCLK is cycled once. The data is taken
by the FPGA on the low to high edge. This is then repeated for the rest
of the bitstream. But as Catalin said, if DONE and INIT are at 1 volt
rather than 0V (or within a few 100 mV of 0V), all of this is pointless,
since something more fundamental is wrong.

>But when I power on the FPGA, must I pull down the Prg/ line ?

No. The FPGA will do a power on reset, which is the equivalent of pulsing
the program pin low. You do need to hold it high, and you must stil wait
for INIT to go high before starting CCLK. If you want to reconfigure, you
need to use the program pin.

> And when the init/ signal pull up after, must I pull up the prg/ pin ?

Yes

>Secondly, you have very good explain the bitstream format. But we are
>agree that all bits on the bitstream must be swap,

NO. When you talk about swaping, you are assuming that the data is
grouped in something bigger than a bit, such as a byte. This may be your
case, depending on the file format you are using. But it is your choice
how you shift the data out to the FPGA. If you choose to shift it out
from the MSB (most significant bit) first, you get a totally different
stream of bits from if you shift the byte out one bit at a time from the
LSB (least significant bit). So swaping depends on how you shift the data.

>so the length count too. So when we see the bistream file with the
>length count 42409 for example like:
>
>0000 0000
>1010 0101
>1010 1001
>
>I must send data in this byte order but swapped of course, so :
>0000 0000 1010 0101 1001 0101
>
>yes ?

NO. the bit are sent 0000 0000 1010 0101 1010 1001
^                           ^
|                           +-- this bit goes in last
+-- This bit goes in first

That is, take each byte, and shift it into the FPGA, MSB first.

>Because I think it's stange for the internal serial latchs to
>swap after the first and the third byte....

They don't. The length count register is just a 24 bit shift register. The
data is shifted in at the LSB end, and after 24 clocks, the first bit in
will now be at the MSB end, and the last bit in will be in the LSB
position. The FPGA knows when the 24 bits have been loaded, and stops
loading the length counter, and starts looking for the first '0' bit
after the filler '1' bits that follow the length count. Then it starts
doing the main job of configuring.

I think you may be helped by running the bitgen program, and having it
create a rawbits file. This is an ascii file, that you can read. The data
that goes into the FPGA is EXACTLY as this file shows it, reading the
lines of text left to right, is the sequence the bits are loaded into the
FPGA.

> Perhaps it's the less significant byte before to
>the most significant ? (but of course with all bits swapped)

No. see above.

>For me, now, when I power on the FPGA, init? is high.

It will go high after config clearing, if program is already high.

>I pull down after Prg/ and wait that init/ is high (true
>of course) and send all bits.

No. If you wont be reconfiguring (without turning power off and back on),
you can start configuring without pulsing program low. Init wont go high
until program has gone high.

>But there a always bit reported on the DOUT pin. So my FPGA has never

Right, or somehow it thinks it has finished configuring. Either way, the
problem seems to be you need to find out why DONE and INIT dont go to a
valid LOW level.

Of course, you might just have a dead chip?

Good luck,

Philip Freidin


Article: 22627
Subject: Re: ANNOUNCE: Embedded Systems Glossary and Bibliography
Date: Mon, 15 May 2000 10:48:45 +0200
Links: << >>  << T >>  << A >>


Jerry Avins wrote:
>
> Result of check: I asked a CS friend (he has a masters degree and is
> active in the profession) if he knew or could guess what a mutex is. He
> had a vague memory that it is a species of mosquito.
>
snip

hehe, I'm not a CS, but I did have a course in real-time systems, and it
was used in the book we used, and as an example was the "sleeping barber
problem"
I can't remember the name of the book but it was probably by Tanenbaum
and it's in the SunOS "Guide to multi-thread programming" too

--Lasse
(+)--------------------------(+)
| Aalborg, Denmark           |
(+)--------------------------(+)


Article: 22628
Subject: Re: Future of FPGAs?
From: Andy Holt <andyh@city.ac.uk>
Date: Mon, 15 May 2000 10:32:25 +0100
Links: << >>  << T >>  << A >>

>
> >: FPGAs will be used mainly for prototyping and educational environment.
> >
>
> Not such a good example, because everything they sell is very high
> priced, so they can afford it.
>
Seeing the price Xilinx is advertising for Spartan II, I would have
thought that only in specialised cases would the higher preparation
costs of Asics be viable.

Andy

Article: 22629
Subject: Re: Future of FPGAs?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 15 May 2000 11:09:36 +0100
Links: << >>  << T >>  << A >>


Andy Holt wrote:

> >
> > >: FPGAs will be used mainly for prototyping and educational environment.
> > >
> >
> > Not such a good example, because everything they sell is very high
> > priced, so they can afford it.
> >
> Seeing the price Xilinx is advertising for Spartan II, I would have
> thought that only in specialised cases would the higher preparation
> costs of Asics be viable.
>
> Andy

One open question is whether the ease of copying an SRAM based FPGA design is
holding back the take up of FPGAs for fairly high volume products. The ways
around this have been discussed to death several times on this ng.. Anybody
have any actual evidence/experience as whether this factor is *really*
inhibiting the growth of the FPGA market.

Any comments from the Vendors ? I would have though that if this is a serious
obstruction then the first Vendor to build a solution into their h/w will clean
up.

Thought: Maybe building such a solution into the h/w would expose the vendor to
legal action if the protected'' design is actually copied or
reverse-engineered.

Implication: Once again fear of the lawyers is stifling innovation.


Article: 22630
Subject: XC1804 JTAG Programming Problems
From: "Peter Schulz" <p.schulz@signaal.de>
Date: Mon, 15 May 2000 13:46:33 +0200
Links: << >>  << T >>  << A >>
We try to program an XC1804 serial PROM via a Parallel Cable III
using the JTAG-Programmer Software with the latest Service Pack installed.
The programming seems to be performed correctly
but both PROM-readback and FPGA-configuration fail.

The boundary scan (JTAG) chain is built up in the following way:

Parallel Cable III  ->  Virtex 600 ->  XC95144XL -> XC1804 -> back to
Parallel Cable III

Chain intitialization is working, the JTAG SW gets the correct device
information.
The Virtex 600 can be configured and the circuit is working fine.
The CPLD 95144 hasn't been tried to configure yet.

Are there any known bugs which can occur in this kind of JTAG chain?

Are there any known bugs concerning the JTAG programmer software?

Are there any known bugs concerning these brand new kind of PROM?

Any kind of information concerning our problem is welcome.

Regards

Peter Schulz
Signaal


Article: 22631
Subject: Re: Future of FPGAs?
From: Andy Holt <andyh@city.ac.uk>
Date: Mon, 15 May 2000 13:35:45 +0100
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:
>

> One open question is whether the ease of copying an SRAM based FPGA design is
> holding back the take up of FPGAs for fairly high volume products. The ways
> around this have been discussed to death several times on this ng.. ...

Another fear rather than copying might apply for digital TV decoders,
DVD players, and the like. That is the probability of crackers being
able to "chip" the unit to disable copy-protection mechanisms just by
supplying ROMs.

Andy

Article: 22632
Subject: Re: HELP - what to choose?
From: Andy Holt <andyh@city.ac.uk>
Date: Mon, 15 May 2000 15:21:42 +0100
Links: << >>  << T >>  << A >>
Thank you all for the replies I have so far received, bith via the
newsgroup and directly by email.

Dave Vanden Bout wrote:
>
> > As for software, the Kanda and Atmel packages come with some, for the
> > Xess one I would also have to spend another $100 for the Foundation > > student edition. > > Buying the Xilinx Student Edition gives you a$30 discount on the XS40 Board.
(I had factored that into the costs I was estimating)
> Also, the new version of the Xilinx Student Edition may offer some additional price restructuring whenever it appears.
Furthermore, it appears that the price from amazon.co.uk is considerably
less than that from amazon.com (how odd!)
Anyhow I now have that on order (I picked-up a remaindered copy of 1.3
that gave me the idea of "playing" with FPGAs)

> I assume you checked all the boards listed at http://www.optimagic.com?

I had used that as the basis for my search, but on rechecking I find two
more possibilites:

There are some Brazilian (www.aee.com.br) boards supporting the Xilinx
chips - not dramatically different from the Xess ones in terms of
features or price (allowing for the voucher price from Xess). As your
book is written with the Xess cards in mind there seems to be little
point in following-up this alternative.

Perhaps more interesting is a Spartan II board from Insight Electronics.
(http://www.insight-electronics.com/xcellence/scalable/kit/spartan/index.html)
At first I thought the low price in the board list had to be a mistake,
but seeing how Xilinx seems to be very aggressive with its pricing for
the Spartan II I am now more inclined to believe it even though I
couldn't find any way of checking the price on the web site.
The plus point is that it would give a much larger device for my money -
one that I can have a high degree of confidence that it is "big enough"
(whereas I suspect the 4010 could be a tight fit).
The catch is that the Spartan II series is not supported by the current
student edition of Foundation and it is not clear whether the ($95) Foundation Base supports the full size range of Spartan II or only the smallest two versions. By the pricing it looks like Xilinx wants to encourage this range to replace the 4000 range and thus I might reasonably hope to see low cost software support. Unfortunately I wasn't committed enough a week ago when a copy of Foundation Base Express sold on eBay for about$50, I should have bought
that and then the decision would have been less difficult.

Thanks once again to
(Dave, Ray, Rick, Don, Tony, & Michel)

Andy

Article: 22633
Subject: Re: HELP - what to choose?
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 15 May 2000 09:33:00 -0700
Links: << >>  << T >>  << A >>


Andy Holt wrote:

>
> <snip> and it is not clear whether the ($95) > Foundation Base supports the full size range of Spartan II. It does. Peter Alfke, Xilinx Applications  Article: 22634 Subject: Re: See if this code can work. From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> Date: Mon, 15 May 2000 09:44:24 -0700 Links: << >> << T >> << A >> Adams wrote in message <8fjerj$2e1u$2@news.cz.js.cn>... >Hi, > >I write the following code to achieve a serial communition between PS2 >keyboard and fpga. One start bit, 8 bits data, 1 parity, 1 stop. >then change it into parallel. The problem is not the code did not work(I >know the pdata assignment should not be like this,I should use shift >register structure). I had changed them into a mess. The confusing thing is >that the synthesizing tool can not recognize my state machine. And it >ignored KBCLK, and the state variable. > >I have tried Xilinx Foundation 2.1i/Fpga Express (use XCS10 LC 84) and >Maxplus 2(use EPM7128sLC84). Neither work. In maxplus2, CNT8 change from S0 >to S1, then S10!! Thean back to S0. In Fpga Express, I can see the >synthesized schematic, it ignored my KBCLK. > >Anyone knows why, please help me. >ARCHITECTURE ONE OF kbps2 IS > type Sreg_type is (S0,S1,S2, S3,S4,S5,S6,S7,S8,S9,S10); > SIGNAL CNT8:SREG_TYPE; >BEGIN >recv: > process(reset,KBCLK,kbdata) Your sensitivity list is wrong. You need to use the correct "template" so the synth tools will know that you want to generate flip-flops. kbdata should NOT be in your sensitivity list - only the clock and reset go there. Remember that flip-flops are sensitive only to clock edges (and the async reset)! -- a ----------------------------------------- Andy Peters Sr Electrical Engineer National Optical Astronomy Observatories 950 N Cherry Ave Tucson, AZ 85719 apeters (at) noao \dot\ edu "A sufficiently advanced technology is indistinguishable from magic" --Arthur C. Clarke  Article: 22635 Subject: Re: Do you know xilinx FPGAs well? From: "Steve Casselman" <sc@vcc.com> Date: Mon, 15 May 2000 11:00:19 -0700 Links: << >> << T >> << A >> You might think about this. http://www.sidsa.es/fipsoc_r.htm 8051 10 bit DAC ADC @800K samples/sec 96 logic blocks (4 4-LUTs and 4 registers) 56 programmable I/O All you would need is a$5 SRAM and you'd have your complete system.

Steve Casselman, President
Virtual Computer Corporation

news:8fglhp$frl$1@nnrp1.deja.com...
> I have to implement the following:
> 1. 8032 microcontroller,
> 2. 64kbytes SRAM,
> 3. some 8 latches and two 3x8 decoders,
> 4. 12kHz Generator
> 5. 16kHz detection
> 6. DTMF dialer.
>
> The above is the customized solution for a telephone set for some
> telecom company.
>
> After some initial study, i think that Virtex could give me solution.
> There is also an A/D converter(which i might need) in the Virtex and
> such a large memory could only be implemented in an Virtex.
>
> But then i thought that since Virtex is expensive, this is not a good
> solution. I thought of SPARTAN II but then SRAM is out.
> What do u thing and suggest.
> Thanks and Regards,
> SHAH
>
>
> Sent via Deja.com http://www.deja.com/


Article: 22636
Subject: Re: XC1804 JTAG Programming Problems
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Mon, 15 May 2000 14:13:20 -0400
Links: << >>  << T >>  << A >>

Peter,
There have been many problems in the JTAG Programming of Xilinx FPGAs.
I believe that SP6 solves many problems but at least one problem remains.
We found that the SPROM had to be the FIRST device in the chain or it
doesn't program properly.  Also watch out for possible bad XC1804s -- the
There are two kinds of problems here -- software problems in the JTAG
program and hardware problems in the SPROM and possibly elsewhere.  Xilinx
will readily admit to the software problems if you probe them enough.
Getting data from them on hardware problems is next to impossible.
Simon

> The boundary scan (JTAG) chain is built up in the following way:
>
> Parallel Cable III  ->  Virtex 600 ->  XC95144XL -> XC1804 -> back to
> Parallel Cable III
>
> Chain intitialization is working, the JTAG SW gets the correct device
> information.
> The Virtex 600 can be configured and the circuit is working fine.
> The CPLD 95144 hasn't been tried to configure yet.
>
> Are there any known bugs which can occur in this kind of JTAG chain?
>
> Are there any known bugs concerning the JTAG programmer software?
>
> Are there any known bugs concerning these brand new kind of PROM?
>
> Any kind of information concerning our problem is welcome.
>
>
> Regards
>
> Peter Schulz
> Signaal
>
>
>
>


Article: 22637
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: "Marc K." <marck@omneon.com>
Date: Mon, 15 May 2000 18:44:59 GMT
Links: << >>  << T >>  << A >>
Tom,

Interesting. I think I've recreated your method via manual routing using
FPGA-Editor on an XCV50E. I don't get any DRC errors.

I wonder if there's another DRC check that's run separately for "proper" DLL
usage, as opposed to the DRC check the FPGA-Editor runs for "allowable
routing". If so, that may explain what you're getting.

Take another look at XAPP133, particularly figure 10. The second DLL isn't
fluff, because routing from either the DLL CLK0/CLK90/...) pin or the BUFG
pin to an IOB O pin does not use the global clock routing, so you'll get
skew. The first DLL drives the output pin with some delay in the path, which
will vary with process, temperature, and voltage. That pin feeds back to the
first DLL, which compensates for those unknown delays, so that output pin
will match the phase of the reference clock. The second DLL accomplishes the
same thing for the internal clock.

You're trying to use one DLL for both functions, but there's only one
feedback pin, so you can't compensate for both the output delay and the
internal clock. I'd guess the error message is poorly phrased. It should
say, simply, that if you're feeding the output of a DLL to a BUFG, you must
take the output of that BUFG to the feedback pin, otherwise you can't
guarantee the phase of the internal clock.

I suggest you follow XAPP133 figure 10, but I hope you have a spare DLL
(gee, it's a -E part, so you should!) and haven't locked pins yet. You
should be able to feed the CLK0/CLK90/... pin directly to multiple IOB O
pins. Don't use a BUFG on that DLL, but do make sure you bring one of the
output clocks back in to the feedback pin. (Aside from using the BUFG, this
is what you've done already, right?) Use the second DLL as diagrammed.
Here's the problem: you will get some skew between the multiple output
clocks. You can minimize the skew with placement, timing constraints, and,
heaven forbid, manual routing. If you think you can live with up to +-500ps
of skew, I think you'll be okay. You will need to make sure the output
clocks are close to each other, though.

Good luck,

Marc

P.S. I sent this on May 12th through Xilinx's comp.arch.fpga mirror
(support.xilinx.com->forums->comp.arch.fpga) and it appeared, but I just
checked comp.arch.fpga from a different news server and I couldn't find it.
Indeed, none of my postings through Xilinx show up here, but they're all
visible from the Xilinx site.


Article: 22638
Subject: Re: ? economical SPROM programmer for Xilinx
From: "Marc K." <marck@omneon.com>
Date: Mon, 15 May 2000 20:05:36 GMT
Links: << >>  << T >>  << A >>
(I posted this 3 weeks ago through Xilinx's mirror of comp.arch.fpga and I
can see it there, but I just checked through a different news server and
it's not visible. So here it is, again. I apologize for the duplication and
the delay.)

Try Roman-Jones, Inc. at http://www.roman-jones.com/

I've used their \$120 programmer and it's fine. It will only program Xilinx
SPROMs, though.

Marc


Article: 22639
Subject: Re: Virtex clock buffers
From: "Marc K." <marck@omneon.com>
Date: Mon, 15 May 2000 20:10:54 GMT
Links: << >>  << T >>  << A >>
(I apologize for the duplicate post. For some reason SOME but not all of my
postings to this newsgroup through Xilinx's comp.arch.fpga mirror do not
show up. I originally posted this response 6 days ago.)

(Jon: Virtex parts don't have XTAL pins.)

Simply put, P213 is a GCLK input (clock 3). This pad connects directly to an
IBUFG, which can only route to a DLL or a BUFG (global clock driver). (NOTE
for others: the GCLK input pins can't be used as outputs!)

Yes, you can get the signal on P213 to your logic, but it must follow the
IBUFG/BUFG path (or through the DLL) and then getting it from a global clock
net to something other than a K (clock), CE (clock enable), and certain
other CLB inputs requires messy routing. The Xilinx tools will do it, but
you'll get long delays.

What you can't do is try to put an IBUF on P213: there isn't one there.

Also, you can't use the syn_noclockbuf on P213: without the BUFG you won't
get a connection to the IBUFG and pad.

If Synplify is attaching an IBUF to P213 it's a Synplify mistake, not a
Xilinx mistake.

Marc

"Matt Gavin" <mtgavin@collins.rockwell.com> wrote in message
news:39132F64.A3CCC710@collins.rockwell.com...
> FPGA gurus,
>
> I am programming a Virtex XC400, after synthesizing
> with Synplify.  Synplify claims to be finding my three clocks
> requiring global buffers (two input clocks, one internal.)
> I am hardwiring the locations of the two input clocks to pins
> 89 and 92 (which of course are global buffer pins).
>
> I am having problems putting a normal (non-clock) input
> on one of the global buffer input pins that I am not using
> for a global buffer (pin 213).   The error message from the mapper
> follows.
>
>    Running directed packing...
>    ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular
> I/O
>       component as required.  The symbol has a constraint (LOC=P213)
> that specifies
>       an illegal physical site for the component.  Please correct the
> constraint
>       value.
>    Problem encountered during the packing phase.
>
> 1.  Shouldn't I be able to use global buffer pins for inputs
> that do NOT require the global buffer?  Recall that synplify
> is instantiating the buffers for me.
>
> 2. Also, is there a way for me to find out which of the four buffers
> are being used for the internal nets requiring clock buffers?
> I can't find it in the logs.
>
> Thanks,
>
>   Matt
>


Article: 22640
Subject: c -> FPGA netlist compiler
From: m_rajanikant@my-deja.com
Date: Tue, 16 May 2000 01:01:11 GMT
Links: << >>  << T >>  << A >>
Hi,
I heard of a C to FPGA netlist complier, Can someone tell me where I
can find this

Thanks
Raj, ASU

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

Article: 22641
Subject: Propogation Delay
From: Douglas Armstrong <site@typhoon.xnet.com>
Date: 16 May 2000 02:17:52 GMT
Links: << >>  << T >>  << A >>
Hello,

I am attempting to determine how much time we have available for
propogation dealy. We're using LVTTL, though we're not sure which
particular driver is best.

We've been looking at the specs, but aren't quite sure what each of the
times represent. What we are looking for is the time from the begining of
the clock period to when the pad starts switching. most of the times seem
be the most relevant number, but not quite it. and how exactly does Tiockp
fit in? also the pin-to-pin paramterters in the back? with and without
DLL? and finally, what exactly does the Clock to Out represent?

and help would be appreciated greatly, thanks!

Article: 22642
Subject: Where can I find resource for USB?
From: "JX" <jiangx1@asme.org>
Date: Tue, 16 May 2000 15:50:22 +0800
Links: << >>  << T >>  << A >>
Hi, All,

My supervisor ask me to design some USB inferace with
FPGA, where can I find any resource to implement that?

Thanks a lot!
Jesse


Article: 22643
Subject: [search] - ISA PnP specs
From: Sebastien Favard <Sebastien.Favard@utc.fr>
Date: Tue, 16 May 2000 14:42:03 +0200
Links: << >>  << T >>  << A >>
Hi,

I search informations about the PnP dialogue between OS like Windows and
ISA board.

Sebastien,


Article: 22644
Subject: [Part II] - Pb FPGA Xilinx config process
From: Sebastien Favard <Sebastien.Favard@utc.fr>
Date: Tue, 16 May 2000 14:54:46 +0200
Links: << >>  << T >>  << A >>
I open a new topic... (after the famous :) "Init/ line - CRC error ???")

I have buying a new XC5202 and I have progress on the programmation
process step.

Firstly, the HDC and LDC/ lines are correctly pull up and pull down
respectively.
During the FPGA programmation step, the header is correctly detected and
its bits are reported on DOUT. Just after the header, DOUT is hold at 5V
:) and during the data stream, no crc error ic occured.

But after these things Done is hold at low and never pull up. So I think
that I have a problem like my length count or perhaps my startup process
? I use in fact CCLK to startup the FPGA, so I put some CCLK rising edge
after the data stream to force my FPGA to start up.

Perhaps anyone has an idea about my new problem ! (maybe the
FPGA banished me ;-) )

Thanks a lot,

Sebastien,


Article: 22645
Subject: Foundation to Mentor
From: "Benoît HAMON" <benoit.hamon@elios-informatique.fr>
Date: Tue, 16 May 2000 14:55:10 +0200
Links: << >>  << T >>  << A >>
Hi,

I use Foundation 1.5i with VHDL and Logiblock module and I try to simulate
and place-route this version on the Mentor tools.

Could you tell me what I need to do (compatibility, files used as .vhd,
etc...)

Thankful for help

B.H.


Article: 22646
Subject: Re: c -> FPGA netlist compiler
From: Ian Miller <miller@lists.lavalogic.com>
Date: Tue, 16 May 2000 13:07:17 GMT
Links: << >>  << T >>  << A >>
We are currently seeking BETA users for a Java to Verilog (Synthesizable
to any FPGA architecture) compiler.  The tool is called "Forge" and is
freely available at our website: http://www.lavalogic.com  Just click on
of our tool.

The "Forge" allows chip designers to write high level algorithmic
descriptions of their chip directly in pure Java, then translate that
description to synthesizable Verilog.

The "Forge" is written in Java and will run on any platform running a
Automated install is supported for Solaris 2.6 and Linux (x86), however
installation instructions are available for any platform.

Sincerely,
Ian

http://www.lavalogic.com

m_rajanikant@my-deja.com wrote:
>
> Hi,
> I heard of a C to FPGA netlist complier, Can someone tell me where I
> can find this
>
> Thanks
> Raj, ASU
>
> Sent via Deja.com http://www.deja.com/

Article: 22647
Subject: PC104+ FPGA Board
From: Jean-Luc Nagel <jean-luc.nagel@imt.unine.ch>
Date: Tue, 16 May 2000 16:54:06 +0200
Links: << >>  << T >>  << A >>
Hello,

I'm looking for a FPGA prototyping board with a PCI
interface, but also with a PC104+ interface (i.e. PCI PC104)

So far I found only a PC104 (ISA) board for prototyping from
nova-engineering (http://www.nova-eng.com/).

Jean-Luc


Article: 22648
Subject: Re: PC104+ FPGA Board
From: Patrick Schulz <schulz@rumms.uni-mannheim.de>
Date: Tue, 16 May 2000 17:06:54 +0200
Links: << >>  << T >>  << A >>
Jean-Luc Nagel wrote:
>
> Hello,
>
> I'm looking for a FPGA prototyping board with a PCI
> interface, but also with a PC104+ interface (i.e. PCI PC104)
Did you have a look at:
http://www.optimagic.com/boards.html

--
Patrick Schulz (schulz@rumms.uni-mannheim.de, pschulz@ieee.org)
University of Mannheim - Dep. of Computer Architecture
68161 Mannheim - GERMANY / http://mufasa.informatik.uni-mannheim.de
Phone: +49-621-181-2720     Fax: +49-621-181-2713

Article: 22649
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: "Marc K." <marck@omneon.com>
Date: Tue, 16 May 2000 19:01:41 GMT
Links: << >>  << T >>  << A >>
Tom,

Here's another idea, if you've locked the output clocks and they're
impossible to route with low enough skew, but it will take two global clocks
and two BUFGPs and two DLLs.
Take your reference clock and feed it to the first DLL's input. This DLL
drives a global clock through a BUFGP, so the BUFGP output must feed back to
the DLL. Use this clock for only one thing: driving the 4 (or more, possibly
many more) output clocks. You'll need a special circuit to make sure the
output clocks are all closely phased. I use two flops, one clocked on the
positive edge, one clocked on the negative edge, arranged as a 2-bit gray
counter (D1 <= !Q0, D0 <= Q1), and take Q0 ^ Q1 (actually, I used Q0 XNOR
Q1) out to the IOB O pin directly. You'll need one instance of this clock
circuit for every output pin, but if you place the flops and the XOR LUT
into a single CLB (two slices, since you're using two different clock edges)
right next to the output pin and make sure routing from the flops to the LUT
to the IOB O pin is controlled (via constraints or manual routing) you
should be able to get better than +-500ps skew among all the output clocks.
As I said, you can have many more than 4 of them, and they can be
distributed across the chip. The second DLL is used as your primary internal
clock. Take one of your clock outputs, route it back to the second DLL, use
a BUFGP with it. That's your clock for all internal logic. Again, since
you're using a BUFGP with the DLL you'll need to feed back this second
BUFGP's output to this second DLL. This clock will be phased to the output
clocks, so you can use it to drive data out and bring it back in. You will
add two DLL's worth of jitter to this clock, though.

One other thing: you'll probably want to make sure the first DLL has 50%
duty cycle compensation turned on.

Good luck,

Marc