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 23675

Article: 23675
Subject: Re: MPEG audio questions...
From: Savekar Santosh <ssavekar@my-deja.com>
Date: Wed, 05 Jul 2000 09:19:41 GMT
Links: << >>  << T >>  << A >>
In article <M5P65.1136$HR.19533@news6-win.server.ntlworld.com>, "gary" <dont.spam@me.net> wrote: > Dear all, > > I am considering implementing an MPEG layer 2 audio decoder in an fpga. > Around 128kbit/s. > > What I need to know is.... > > (1) How complex is the decoder, how much logic would I need? I think with highly optimized design you should be able to do the audio decoder layer-I, not sure about layer-II, in around 8K gates or so. I am not thinking about the space to store constants here. See: http://www.tsec.com/p_audio.htm > > (2) Do you have to pay to use MPEG in your own codecs? You have to pay only if you buy the standards from ITU. which are priced at around$125. But you can get the know-how by some
other means such as free sources on web.

>
> All help much appreciated.
>
> Gary.
>
>

Good luck,
Santosh

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


Article: 23676
Subject: Virtex-E PCI (MB with 3.3Vsignaling)
From: Tobias-Dirk Stumber <Tobias.Stumber@de.bosch.com>
Date: Wed, 5 Jul 2000 12:12:34 +0200
Links: << >>  << T >>  << A >>
Hi !

Since Virtex-E does not allow to be used in
PCI systems with 5V signaling level, I search
for (cheap) motherboards with 32bit/33MHz
PCI slots that have 3.3V signaling level.
(We don need more bandwidth and want to
use Virtex-E because its cheaper than our
currently used Virtex.)

Perhaps there are none and only 66MHz PCI
systems use (require!) 3.3V signaling. Any
(cheap) motherboards that supply this ?

Thanks,
Tobias


Article: 23677
Subject: Re: Serial Number embedded in PROM.
From: dmac <dmac@cutme.matter200.demon.co.uk>
Date: Wed, 05 Jul 2000 10:54:08 GMT
Links: << >>  << T >>  << A >>

As with many others here I don't think you will have any problem in
reading the PROM but . . .

The main problem may be in the data management and programming of the
proms. As your proms will no longer be identical yo will not be able to
use a gang programmer and creation of unique data streams for each prom
may be a real PITA.

H/W upgrades also become a problem eg. do you want an upgraded board to
bear the same serial no as before? Proms cannot be sent out to third

These things are not really something you want on a volume product - is
that a problem.

In a similar situation I have stored s/n etc in a little bit of EEprom
in a Dallas RTC - not much use if you don't want an RTC, but other
incredibly small (and cheap!) devices might suit your needs.

Dave

dmac


Article: 23678
Subject: Re: Serial Number embedded in PROM.
From: Etienne Racine <etienne@cae.ca>
Date: Wed, 05 Jul 2000 07:52:36 -0400
Links: << >>  << T >>  << A >>
Hi Kent,

korthner@my-deja.com wrote:

> I'm trying to think up a not-too-difficult way of adding a serial
> number to the Serial PROM used to program a Xilinx Spartan FPGA.
>
> The intent would be to use this as the Card Serial number, and once the
> FPGA was initialized, it would then go and read the PROM itself.

If the PROM is a XC18V00, there are 32 bits of user-defined data in the
form of the JTAG instruction USERCODE (is 32 bits enough?). The resulting
bitstream will of course be slightly different for each PROM, although I
believe USERCODE can be modified after configuration (confirm with Xilinx
first). If so, a single bistream may gang-program multiple PROMs, then each
PROM could be updated later in the process with its own serial number.

JTAG must be used to readback the usercode from the FPGA. You don't need a
full-fledged JTAG controller on your board, however, since you could add to
your FPGA design a small core that serially shifts out/in the proper values
to issue a USERCODE instruction to the PROM. You just need to be careful
because you don't want to mess around with your JTAG signals.

Just my 0.02$... Regards, Étienne. -- ______ ______ *****/ ____// _ \_\************************************************* * / /_/_ / /_/ / / Etienne Racine, Hardware Designer * * / ____// __ /_/ Visual Systems Engineering * * / /_/_ / / /\ \ \ CAE Electronics Ltd. * */_____//_/_/**\_\_\*************************************************  Article: 23679 Subject: help making // cable III xilinx From: Bernard Bertrand <bertrand@olfac.univ-lyon1.fr> Date: Wed, 05 Jul 2000 15:29:47 +0200 Links: << >> << T >> << A >> Hello, I search someone who was make a parallele cable III (HW-JTAG-PC) Xilinx. If YES a this question. Have you use this cable with free webpack soft xilinx. B.Bertrand bertrand@olfac.univ-lyon1.fr  Article: 23680 Subject: tutorial on configurable system-on-chip design is available From: Dave Vanden Bout <devb@xess.com> Date: Wed, 05 Jul 2000 09:49:23 -0400 Links: << >> << T >> << A >> XESS Corp. is releasing the second section of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html. We will release a new section each week. Each section describes a design example for the Triscend configurable system-on-chip device (CSoC). The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both repr ogrammable. The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||  Article: 23681 Subject: Re: BIST in FPGAs? From: Greg Neff <gregneff@my-deja.com> Date: Wed, 05 Jul 2000 13:57:12 GMT Links: << >> << T >> << A >> In article <3962BAA9.4FBDB7C1@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: > I disagree that you can't get 100% coverage for test. I don't think Phil or I said that it can't be done, but depending on the situation it can take twice as much (or more) work to test 100% than to test 99%. Often it is acceptable to achieve a reasonable level of coverage. It's a tradeoff between fault coverage and project development time/cost. > I am sure that Xilinx tests every chip they make 100%. I sure as heck hope so :-) > Since the chip is fully > programmable, I doubt that they needed to design in special test > circuitry or modes. I would bet my last dollar that the tools and information that Xilinx test engineers have at their disposal are far better than what we have. > Certainly this may take more than a single bit file. > But I am sure that you can test every transistor, every wire and every > connection in a Xilinx FPGA if you need to do that. > > As I said in my other post, I once met an engineer who was designing bit > files for Xilinx chips to do 100% test in military systems. They would > do a complete test of the hardware every time they powered up. I think > this was in the XC3000 and XC4000 parts. > I sent a reply to that post, but it looks like it got lost in the ether. Anyway, I'm sure that it is possible to do, if you have the right tools and information. Peter said it could be done, but he didn't give us any pointers as to how to do it properly. It seems to me that it would be a very long, tedious process to ensure that your bitstream tests all (or even 99%) of the transistors on the FPGA, using the P&R tools that are supplied to us by Xilinx. I would love to see your associates' V&V of his test methodology and coverage. I prefer to build BIST logic into the mission bitstream, so that the logic and interconnect that are in use can be tested, without having to worry about testing resources that are not in use. Also, the test logic becomes part of the documentation and V&V process for the mission logic, so a separate set of documentation is not needed for functional test design(s). -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.  Article: 23682 Subject: Re: BIST in FPGAs? From: Rickman <spamgoeshere4@yahoo.com> Date: Wed, 05 Jul 2000 11:06:24 -0400 Links: << >> << T >> << A >> Greg Neff wrote: > > In article <3962BAA9.4FBDB7C1@yahoo.com>, > Rickman <spamgoeshere4@yahoo.com> wrote: > > I disagree that you can't get 100% coverage for test. > > I don't think Phil or I said that it can't be done, but depending on > the situation it can take twice as much (or more) work to test 100% > than to test 99%. Often it is acceptable to achieve a reasonable level > of coverage. It's a tradeoff between fault coverage and project > development time/cost. Yes, it is certainly a nearly asymtotic function where it gets harder and harder to cover the entire chip in one design (or impossible). But the beauty of an SRAM based chip is that you can design multiple bitfiles and (likely) get 100% coverage very easily (in relative terms). > > I am sure that Xilinx tests every chip they make 100%. > > I sure as heck hope so :-) > > > Since the chip is fully > > programmable, I doubt that they needed to design in special test > > circuitry or modes. > > I would bet my last dollar that the tools and information that Xilinx > test engineers have at their disposal are far better than what we > have. Certainly they have better info. But I would bet that info is available under NDI. The person I met who was doing this had gotten a lot of info from Xilinx. > I sent a reply to that post, but it looks like it got lost in the > ether. Anyway, I'm sure that it is possible to do, if you have the > right tools and information. Peter said it could be done, but he > didn't give us any pointers as to how to do it properly. I agree that it would take support from Xilinx. I wouldn't have an idea of how to test all the interconnect in an FPGA. When I use the chip editor, I don't even understand all of the connections! I really don't see how people can hand route chips. I used to know someone who did that, always! > It seems to me that it would be a very long, tedious process to ensure > that your bitstream tests all (or even 99%) of the transistors on the > FPGA, using the P&R tools that are supplied to us by Xilinx. I would > love to see your associates' V&V of his test methodology and coverage. > > I prefer to build BIST logic into the mission bitstream, so that the > logic and interconnect that are in use can be tested, without having to > worry about testing resources that are not in use. Also, the test > logic becomes part of the documentation and V&V process for the mission > logic, so a separate set of documentation is not needed for functional > test design(s). Certainly BIST scan based logic is much easier than trying to do 100% coverage testing, but the full coverage testing will work with any design in that chip and not use any resources in the running design. I would love to hear from Peter Alfke about the willingness of Xilinx to share their test info for bit files that users can use to do 100% coverage testing of the chip. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com  Article: 23683 Subject: Re: BIST in FPGAs? From: Peter Alfke <palfke@earthlink.net> Date: Wed, 05 Jul 2000 16:38:01 GMT Links: << >> << T >> << A >>  Rickman wrote: > I would love to hear from Peter Alfke about the willingness of Xilinx to > share their test info for bit files that users can use to do 100% > coverage testing of the chip. Yes, I have helped people get that information, usually under non-disclosure (NDA). As Xilinx gets bigger, the procedure may have gotten more complicated. Please contact Marketing with a formal request. I cannot help you now, because I am on vacation, jumping on an airplane in a few hours. Destination: Provence. I may need retraining when (if) I came back. :-) Peter Alfke  Article: 23684 Subject: Re: on arbitrary m-cycle n-bit lfsrs From: "Jan Gray" <jsgray@acm.org> Date: Wed, 05 Jul 2000 17:04:14 GMT Links: << >> << T >> << A >> "Jan Gray" <jsgray@acm.org> wrote in message news:vWe85.1205$q94.384510@paloalto-snr1.gtei.net...

>        n w 8-back
>        - - ------
>        0 0
>        1 1
>        2 3
>        3 7
>        4 E
>        5 D
>        6 B
>        7 6
>        8 C 0
>        9 9 1
>       10 2 3 8-cycle [2-9]: complement d0 when w==9 maps 2=>3
>
>     lfsr 4-bits 8-cycle=9
>     lfsr 4-bits 8-cycle: d0=xnor(q3,q2, /*9*/and(q3,~q2,~q1,q0));
>
> Here w[2]=3, w[9]=9, and w[10]=2.  If we complement the lfsr input bit
shift
> into w[10], we would have w'[10]=3 and the lfsr would cycle
> 3,7,E,D,B,6,0,1,3,...

Correction: 3,7,E,D,B,6,C,9,3, ...

One other comment.  If you build an m-cycle n-bit lfsr with m < 2^n - 1, and
reset it to the bit pattern 0000...0, and if 0000...0 is not in the m-cycle,
then it may take up to 2^n - m-1 cycles for the counter to first reach a
valid m-cycle bit pattern.  In the above example, it takes 2 cycles for the
lfsr to first reach an m-cycle bit pattern 0x3, and 9 cycles (9 > 8) to
first reach the terminal m-cycle bit pattern 0x9.

If you were to design, e.g. a 3-cycle 6-bit lfsr (for some strange reason)
such as

lfsr 6-bits 3-cycle: d0=xnor(q5,q4, /*2D*/and(q5,~q4,q3,q2,~q1,q0));

it takes 37 cycles before it reaches the bit pattern 0x1B and starts its
3-cycle (0x1B, 0x36, 0x2D, 0x1B, ...).  If this is not acceptable, you must
of course ensure you reset the lfsr to some valid bit pattern in the
m-cycle.

Jan Gray
Gray Research LLC


Article: 23685
Subject: Re: Serial Number embedded in PROM.
From: Jason.Wright@Cygnion.com (Jason T. Wright)
Date: Wed, 05 Jul 2000 17:24:34 GMT
Links: << >>  << T >>  << A >>
On Wed, 05 Jul 2000 01:45:26 -0400, Rickman <spamgoeshere4@yahoo.com>
wrote:

>korthner@my-deja.com wrote:
>>
>> Thanks for the advice, Rick.
>> That's what I was thinking of doing.  I know that I can't drive CCLK
>> after startup, and one of the others (Forget which), so I figured I'd
>> connect them to an extra FPGA pin(s).
>
>PROG-, DONE, CCLK are the ones that can't be used for anything else.
>Also DOUT I think. INIT- and DIN are user IOs after config. So you would
>need to provide a user IO connections to DONE/CE- and CCLK/CLK.
>
>
>> And figured I'd put the serial number in the last spot in the PROM, and
>> at SerialNumberReading time, I would just shift everything into an n-
>> bit shift register until the PROM was empty, and whatever was left in
>> the shift register, that's my serial number.
>
>Yes, that would work fine. You will need a counter matched to the size
>of your PROM to stop it.
>
What about just monitoring the CEO of the PROM, and then only shifting when
CEO is high?

Jason
>
>> I'm missing something, I think.  I've seen other people mention using a
>> micro to boot a FPGA. . . . . Why?  If you're not using anything fancy
>> like reprogrammability or readback, isn't it easier/cheaper to just
>> plug a PROM in a socket, and let the FPGA suck up the bitstream itself?
>
>There is no reason to use a micro unless you can use it for some other
>tasks as well. In my case I was looking for a way to replace the one
>wire serial number part (in which I would also use the EEPROM/PROM) and
>realized that it could replace a couple of other parts. Now I am looking
>for the perfect uC that will replace all the misc logic chips on my
>board. If I could find one that had three analog comparators as well as
>the Flash, EEPROM, UART and a dozen or more IOs I would have it made.
>But it is hard to find everything in one part.
>
>
>> That's the other thing we're looking at.  I assume, then, that you've
>> got the Dallas part (2401?) up and running, no problem?  Can you by any
>> chance let me know how big the onewire-control logic inside the FPGA
>> is?  I have a *very* little amount of space left (20% of a Xilinx
>> Spartan '05), so I figure I don't have what it takes to do the timing
>> requirements.  If you could send me a copy of the VHDL code, that'd be
>> wonderful.  But if you can't, I understand completely.
>
>The Dallas part is very easy to use. The documentation is not real clear
>though. But you can read between the lines and figure out what is going
>on. We used the on board DSP to do all this so I don't know how large
>the circuit would be in an FPGA.
>
>You just need a few timers and a finite state machine (FSM). The one
>wire chip communicates in a polled mode where every bit sent in either
>direction is started by the FPGA with a one uS low pulse (all drivers
>are OC and there is a single 4.7K pullup). In that 1 uS the one wire
>chip will pick up the ball and drive it to a zero if it is sending you a
>zero or leave it float if it is sending you a one. A zero is held for
>another 15 uS max. If you are sending a zero or one, you do the same (1
>uS v. 15 uS). There is also a reset pulse sent to the one wire chip
>which is a zero for over 60 uS.
>
>This is how you send/receive bits. There is then a protocol on top of
>that to read the data in the one wire chip and to program it. If you
>just need to read the serial number and nothing else, I think there is a
>command to read it out cold. The other commands require you to "address"
>the chip with the SN.
>
>This is all a bit hazy as it has been awhile since I looked at it and I
>did not do the coding. But this is the jist of it. Certainly the bit
>level is not hard to do if you have a clock handy (and who doesn't?).
>The higher level protocol will take a bit of FSM design.
>
>But if you are short on free hours, I could do the VHDL for you. It
>might even save you a little time/money since I have a leg up on the one
>wire parts and I can even test the VHDL on my board.
>
>Maybe someone else has done this in VHDL?
>
>
>--
>
>Rick Collins
>
>rick.collins@XYarius.com
>
>removed.
>
>
>
>Arius - A Signal Processing Solutions Company
>Specializing in DSP and FPGA design
>
>Arius
>4 King Ave
>Frederick, MD 21701-3110
>301-682-7772 Voice
>301-682-7666 FAX
>
>Internet URL http://www.arius.com

Jason T. Wright
Cygnion Corp

Article: 23686
Subject: Re: 2.1i better than 1.5?
From: Jason.Wright@Cygnion.com (Jason T. Wright)
Date: Wed, 05 Jul 2000 17:42:02 GMT
Links: << >>  << T >>  << A >>
I believe the defaul settings for par are different.

Jason

On Tue, 04 Jul 2000 10:22:34 +0300, Yekta Ayduk <yekta@netas.com.tr> wrote:

>I installed  Foundation 2.1i and all service packages ,but the placement
>and routing  results are  worse in comparision to 1.5  . I used the
>same  table seed entry ,routing effort ,ucf files . The parts are XC5204
>and XS20 .
>Did anybody  get similar results?
>

Jason T. Wright
Cygnion Corp

Article: 23687
Subject: Re: Serial Number embedded in PROM.
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 05 Jul 2000 14:08:49 -0400
Links: << >>  << T >>  << A >>
"Jason T. Wright" wrote:
>
> On Wed, 05 Jul 2000 01:45:26 -0400, Rickman <spamgoeshere4@yahoo.com>
> wrote:
> >> And figured I'd put the serial number in the last spot in the PROM, and
> >> at SerialNumberReading time, I would just shift everything into an n-
> >> bit shift register until the PROM was empty, and whatever was left in
> >> the shift register, that's my serial number.
> >
> >Yes, that would work fine. You will need a counter matched to the size
> >of your PROM to stop it.
> >
> What about just monitoring the CEO of the PROM, and then only shifting when
> CEO is high?
>
> Jason

That's a good idea as long as you have the spare IO line. Saves a number
of CLBs if you are tight on space.

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 23688
Subject: Re: Virtex Global Set Reset
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 5 Jul 2000 11:16:56 -0700
Links: << >>  << T >>  << A >>
SteVe wrote in message <3961DD67.10F9889@xxx.it>...
>In my Virtex design (written in VHDL) I have a reset signal (N_RST).
>This signal is active low and resets all the FFs of the design,
>excluding a few of them (which haven't a set/reset signal).
>My question is: can I use the Global Set Reset resource? The problems I
>see are two:
>- the GSR net is active high, but my N_RST signal is active low;

An inverter will be inserted between your reset signal and the GSR.

>- the GSR net reaches all the FFs: what happens to the FFs of my design
>that have not a S/R signal?

The synthesis tool should complain that not all flops are set/reset by the
reset signal and it won't infer a global reset.  You can fix that by
hand-instantiating the GSR or just making sure all flops have a reset (which
is preferred).

-- 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: 23689
Subject: Re: Altera Ships Largest PLD
From: husby@fnal.gov (Don Husby)
Date: Wed, 05 Jul 2000 18:59:15 GMT
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> wrote:
> I know what you mean, but this would make the complexity of inventory
> very much harder. This is especially a big problem for micros, you need
> to vary not only the RAM/ROM and all the usual things that micros
> tailor, but you also need to vary the size of the FPGA and the package
> pins (much more so than on a micro). They would have to do a sparse
> matrix implementation of that N dimensional array.
>
> I do that Lucent is selling FPGAs not much different from Xilinx parts
> that have an on board PCI bus interface. I don't know how well it is
> selling though. Lucent seems to be very tight on information on new
> products and sales.

In keeping with their non-marketing strategy, Lucent announced their latest
chip during a 5-day holiday.
http://www.lucent.com/micro/NEWS/PRESS2000/070300a.html

Which claims (in addtion to 4-port block ram and LVDS I/O):
" ... and has built-in 8-bit, 16-bit and 32-bit interfaces to the PowerPC* 860
and PowerPC II microprocessors. It uses a new embedded AMBA** specification
2.0 AHB multi-master system bus to handle communication at rates up to 200 MHz
between the microprocessor interface, configuration logic, all embedded-block
RAMs, FPGA logic and embedded standard-cell blocks ..."

This becomes very attractive for an embedded CPU + FPGA combination.
Unfortunately, I have been fighting with the Lucent software for the past
2 weeks, and am just about ready to try brand X again.  (Even though it
takes an XCV800 to implement a circuit that fits in an OR3L165).

--
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: 23690
Subject: Re: Altera Ships Largest PLD
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 05 Jul 2000 15:35:45 -0400
Links: << >>  << T >>  << A >>
Don Husby wrote:
> In keeping with their non-marketing strategy, Lucent announced their latest
> chip during a 5-day holiday.
>  http://www.lucent.com/micro/NEWS/PRESS2000/070300a.html
>
> Which claims (in addtion to 4-port block ram and LVDS I/O):
> " ... and has built-in 8-bit, 16-bit and 32-bit interfaces to the PowerPC* 860
>   and PowerPC II microprocessors. It uses a new embedded AMBA** specification
>   2.0 AHB multi-master system bus to handle communication at rates up to 200 MHz
>   between the microprocessor interface, configuration logic, all embedded-block
>   RAMs, FPGA logic and embedded standard-cell blocks ..."
>
> This becomes very attractive for an embedded CPU + FPGA combination.
> Unfortunately, I have been fighting with the Lucent software for the past
> 2 weeks, and am just about ready to try brand X again.  (Even though it
> takes an XCV800 to implement a circuit that fits in an OR3L165).

If this is what I think it is, you have the same capability on the OR3T
family. They have the MPI, a built in interface for two uPs. "The MPI is
programmable to operate with PowerPC MPC800 series microprocessors and
Intel*i960* J core processors". You can use it to download the FPGA
bitstream and then use the same interface to talk to the innards after
configuration is complete. There is even an ID register to identify the
specific FPGA in case you have multiple parts that will fit your
"socket" on the board. It sounds like they suped it up a bit in the new
version though.

I never used the interface since it would have required me to emulate
the same interface and I am using a DSP.

The new chips sound like they will continue to give Xilinx a run for the
money in the large telecom accounts. But there will not be much for the
small guys like us. (I guess I should speak for myself!)

I currently am using a couple of the Lucent parts on a board I build. I
recently asked Lucent if they could meet the pricing that I can get on
similar new Spartan II parts. They were unwilling to do that on the
larger of the two parts and in fact raised the price on me. So I will
likely be switching when the new Xilinx parts are out.

The bottom line is that Xilinx has a much larger volume (I assume) than
Lucent and will continue to support a broad range of parts in different
sizes, packages (although not as many combos as I would like) and new
technologies. And on top of it, they seem to be committed to keeping a
low priced line available.

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 23691
Subject: Thanks for the tip
Date: Wed, 5 Jul 2000 13:36:20 -0600
Links: << >>  << T >>  << A >>
Phil,

As usual, you hit the nail right on the head. Maybe I'm oldfashioned but I
like to see the results of each synthesized block. Now I can get my post
synthesis schematic into simulatable form. To do it I had to use the updated
Virtex library from Xilinx and update the Viewlogic Fusion simulator and
utility but it was ten's of megabytes.

.

INIT\=@INIT

I have put a .pdf copy of the Viewgen'ed schematic up on my web site
like. I tested it in the simulator and it works correctly!

Thanks to all for the help.

********************************************************************
Pete Dudley
Sandia National Labs
Dept 2336  MS 0505
PO BOX 5800
Albuquerque, NM 87185
voice: 505.844.5565   fax: 505.844.2925   email: padudle@sandia.gov
Signal Processing in Hardware and Software
********************************************************************

"Philip Freidin" <fliptron@netcom.com> wrote in message
news:8jmabg$lip$1@slb7.atl.mindspring.net...
> In article <8jm9qe$ji0$1@slb7.atl.mindspring.net>,
> Philip Freidin <fliptron@netcom.com> wrote:
> >
> >libraries are supposed to be able to simulate ROMs with init=xxxx
> >attributes attached. This was fixed about 6 months ago. No announcement
> >was made, so you just needed to trip over the updates.
> > ... more helpful stuff deleted ...
>
> You might also want to look at http://support.xilinx.com/techdocs/5968.htm
>
> Philip Freidin
>


Article: 23692
Subject: Re: Viewlogic schematic from Synplify edif output?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 5 Jul 2000 12:53:20 -0700
Links: << >>  << T >>  << A >>
Rickman wrote in message <395ED46E.D072C66A@yahoo.com>...

>Now if I can just get them to let me enter a single equation for the LUT
>instead of having to calculate the hex contents myself.

FPGA Editor?

--
-----------------------------------------
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: 23693
Subject: Timing Simulation on wildforce board
From: Anurag Tiwari <atiwari@cs.wright.edu>
Date: Wed, 5 Jul 2000 17:00:00 -0400
Links: << >>  << T >>  << A >>

Has anyone ever ran a timing simulation using wildforce reconfigurable
computing boards, the timing simulation which incorporates the
PE_logic_core design as well as simulation model of the board??

--Anurag


Article: 23694
Subject: VHDL code for LFSR
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 05 Jul 2000 17:35:24 -0400
Links: << >>  << T >>  << A >>
I was reviewing the LFSR Testbench by Jean Nicolle and I am not sure,
but I thought there might be a bug in some of the VHDL code it
generates.

The program seems to be very flexible. It allows you to design any of
several forms of LFSRs and will show you a schematic of the design
generated as well as code in AHDL, VHDL and Verilog. VHDL is the only
one I am familiar with and I thought there might be a bug in the clocked
process. The variable "feedback" is assigned a value inside the if
clock'EVENT statement which seems to me will generate an additional,
unwanted FF. The only FFs in the design should be LFSR(0:3). Am I right
or is this code fine?

You can find the program at http://www.jps.net/kyunghi/LFSR/. Check it
out!

entity LFSR4_9 is
port(clock: in bit;
q    : out bit_vector(3 downto 0));
end;

architecture RTL of LFSR4_9 is
signal LFSR: bit_vector(3 downto 0);
begin
process(clock)
variable feedback: bit;
begin
if clock'EVENT and clock='1' then
feedback := LFSR(3);
LFSR(0) <= feedback;
LFSR(1) <= LFSR(0) xor feedback;
LFSR(2) <= LFSR(1);
LFSR(3) <= LFSR(2);
end if;
q <= LFSR;
end process;
end;

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 23695
Subject: Re: Viewlogic schematic from Synplify edif output?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 05 Jul 2000 17:36:41 -0400
Links: << >>  << T >>  << A >>
On the schematic!!!

Andy Peters wrote:
>
> Rickman wrote in message <395ED46E.D072C66A@yahoo.com>...
>
> >Now if I can just get them to let me enter a single equation for the LUT
> >instead of having to calculate the hex contents myself.
>
> FPGA Editor?
>
> --
> -----------------------------------------
> 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

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 23696
Subject: Re: Powering XCV300
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 05 Jul 2000 22:47:54 +0100
Links: << >>  << T >>  << A >>


Tobias-Dirk Stumber wrote:

> > From some experiments with a controllable power supply, I came to have a
> > mere conjecture that the 2.5V power supply from a linear regulator(LT1076)
> > is not really tracking fast enough to meet the changes in Virtex' current
> > consumption. When the 2.5V power is supplied from power supply, the card
> > kept working over night.
>
> Are you completely sure your card fails because of power supply problems ?
> You could propably check this with a dummy design for your virtex with a lot
> of noise (toggle-flip-flops etc.)
>
> In "massive test operation" a lot of systems fail after a undefinable time
> (minutes
> to days). Ours did, too. But at last it was an interrupt handling problem
> which was
> caused by an extremely rare combination of things happening at the same
> time.
> Your problem may be of this nature, too.
>

Another thing is that even slight variations in power supply, temperature etc.
can expose problems with FFs used to sample asynchronous data.


Article: 23697
Subject: Re: VHDL code for LFSR
From: " Srinivasan Venkataramanan" <venkataramanan.srinivasan@philips.com>
Date: Wed, 5 Jul 2000 21:50:23 GMT
Links: << >>  << T >>  << A >>
Hi,

Rickman <spamgoeshere4@yahoo.com> wrote in message
news:3963AA1C.75948386@yahoo.com...
> I was reviewing the LFSR Testbench by Jean Nicolle and I am not sure,
> but I thought there might be a bug in some of the VHDL code it
> generates.
>
> The program seems to be very flexible. It allows you to design any of
> several forms of LFSRs and will show you a schematic of the design
> generated as well as code in AHDL, VHDL and Verilog. VHDL is the only
> one I am familiar with and I thought there might be a bug in the clocked
> process. The variable "feedback" is assigned a value inside the if
> clock'EVENT statement which seems to me will generate an additional,
> unwanted FF. The only FFs in the design should be LFSR(0:3). Am I right
> or is this code fine?
>

I think the code is JUST FINE :-) Since the "feedback" is a VARIABLE and
not a SIGNAL
it shouldn't give you extra FF.

Regards,
Srini

> You can find the program at http://www.jps.net/kyunghi/LFSR/. Check it
> out!
>
>
> entity LFSR4_9 is
>   port(clock: in bit;
>        q    : out bit_vector(3 downto 0));
> end;
>
> architecture RTL of LFSR4_9 is
>   signal LFSR: bit_vector(3 downto 0);
> begin
>   process(clock)
>     variable feedback: bit;
>   begin
>     if clock'EVENT and clock='1' then
>       feedback := LFSR(3);
>       LFSR(0) <= feedback;
>       LFSR(1) <= LFSR(0) xor feedback;
>       LFSR(2) <= LFSR(1);
>       LFSR(3) <= LFSR(2);
>     end if;
>     q <= LFSR;
>   end process;
> end;
>
>
> --
>


Article: 23698
Subject: Re: Altera Ships Largest PLD
From: husby@fnal.gov (Don Husby)
Date: Wed, 05 Jul 2000 21:54:27 GMT
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> wrote:
> If this is what I think it is, you have the same capability on the OR3T
> family. They have the MPI, a built in interface for two uPs. "The MPI is
> programmable to operate with PowerPC MPC800 series microprocessors and
> Intel*i960* J core processors".

Yeah, except that the 3T is limited to an 8-bit data bus.  With a high
performance 32-bit CPU interface, it makes it feasible to interface the
OR4T to your 32-bit DSP with minimum (hopefully 0) logic.

> I never used the interface since it would have required me to emulate
> the same interface and I am using a DSP.
>
> The new chips sound like they will continue to give Xilinx a run for the
> money in the large telecom accounts. But there will not be much for the
> small guys like us. (I guess I should speak for myself!)

Historically, I think the price/performance of Orcas has been better
than Xilinx (ie OR2 vs X4K/spartan), especially if you have high pin/logic
ratio, or if you push them to the performance edge and diddle the mapping
and placement.

It looks like Xilinx is doing better with this generation, probably because
Altera has released their own "Spartan" series.  (Although I may learn
otherwise when I port this design to Xilinx.)

> The bottom line is that Xilinx has a much larger volume (I assume) than
> Lucent and will continue to support a broad range of parts in different
> sizes, packages (although not as many combos as I would like) and new
> technologies. And on top of it, they seem to be committed to keeping a
> low priced line available.

Plus they seem to have a lot more (and better?) software support behind the
chips.  I especailly like the fact that Xilinx appears to allow exact mapping
(e.g. put this signal on this CLB pin dammit!) to be specified in VHDL code.
Lucent seems to have a long way to go with the OR3T PAR software.  For
example, it won't swap pins on a simple 8-bit D-register or tristate bus
in order to meet timing.  I ended up doing this myself by teasing the VHDL
code, but it takes 1-2 hours of effort to get something like that right, and it
will probably break when the next software version is released.

--
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: 23699
Subject: Re: Virtex-E PCI (MB with 3.3Vsignaling)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 05 Jul 2000 23:16:23 +0100
Links: << >>  << T >>  << A >>


Tobias-Dirk Stumber wrote:

> Hi !
>
> Since Virtex-E does not allow to be used in
> PCI systems with 5V signaling level, I search
> for (cheap) motherboards with 32bit/33MHz
> PCI slots that have 3.3V signaling level.
> (We don need more bandwidth and want to
> use Virtex-E because its cheaper than our
> currently used Virtex.)
>
> Perhaps there are none and only 66MHz PCI
> systems use (require!) 3.3V signaling. Any
> (cheap) motherboards that supply this ?
>
> Thanks,
> Tobias

It would give you wider access to cheap motherboard if you buffer you
PCI through QuickSwitch type parts. These, originally supplied by
Quality Semiconductor - now part of IDT, are really just a bunch of pass
transistors that clamp the output voltage to about Vcc-0.7. The trick is
to set down from the nominal 5V to 3.9, they take almost no power so a
simple Zener is sufficient. We have solved the 5V/3.3V PCI problem in
this way for a long time as do a lot of [older] motherboards.

Other suppliers of these type of parts are Pericom & Phillips.