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 18925

Article: 18925
Subject: Re: Need advice on interfacing SDRAM modules
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 22 Nov 1999 03:12:54 -0500
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> I think one-hot coding is still the best.  The problems you mention can
> almost always be fixed by using some combination of pipelining and parallel
> state machines.  For example, the problem of 6 different paths leading to
> the IDLE state can be fixed by adding two flip flops.  The input to each is
> the OR of three of the 6 paths, but one cycle early.  Now you have only two
> paths from these flip flops (but you have more than one bit on at the same
> time).  Also I find that it is unwise to add unnecessary control logic just
> to reduce the number of states.  It is better to have duplicate states which
> lack control logic and use output flip flops to merge these states into the
> control signals that they generate.  Most steps of my state machines reduce
> to simple shift registers with no steering logic.

The precalculation of state trasistions is useful if you can afford the
latency of making that decision. This is not always an option. For
example, if you are optimizing your SDRAM controller, you may want to
have transitions from the last state of a write to the first state of
the read and vice versa without going through the IDLE state. If you
pipeline the decision, you will delay a request that comes in on that
last clock cycle.

Likewise, by pushing some of your logic to the backside of the state
FFs, you again add a latency. Sometimes you can live with a little
additional combinatorial delay. Other times you must pipeline the
outputs with another register delay. It just depends on your
application. I used the registered outputs on my SDRAM controller. This
caused the SDRAM to be one clock cycle behind the actual FSM and
therefore I needed to allow one extra clock cycle delay before clocking
the data on a read. But then I had the time to do this. Other
applications won't. I expect this one to be latency sensitive, but I
don't know.

> One other technique is helpful for this: break the problem into multiple
> smaller parallel state machines.  On the output side this often means using
> synchronous set/reset flip flops to make extended pulses.  Why OR 8 states
> into a single control line which is on for 8 consecutive cycles, when all
> you need is two?  One for when it turns on and one for when it turns off.
>
> On the input side, think subroutines.  The main controller has IDLE and
> BUSY states, and generates START signals for the subroutine state machines.
> These give DONE signals back to the main controller to break it out of the
> BUSY states.

Yes, these are all good ways to work the problem. But if you are looking
to max the true speed and not just the clock speed, you may need to use
fewer clock cycles in the latency.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

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: 18926
Subject: Trouble with ATMEL's AT40K20
From: "Filip S. Balan" <balan@uni-mb.si>
Date: Mon, 22 Nov 1999 11:14:49 +0100
Links: << >>  << T >>  << A >>
I have the following problem:

Even with a very simple design (cca. 500-bit shift register)
I was unable to get a correct working FPGA. With a even
more simpler design (cca. 128-bit shift register), that works
fine on SOME cell locations I found out, that the INTIRE 1'st column
of cells (and unfortunately some other cells/paths to) won't work.

Damged FPGA's (series) , faulty software ...??
Any similar problems?

Filip S. Balan
balan@uni-mb.si

P.S.
1. Chips:
I have 4 chips, but all of them are working exactly equal - faulty :-((
**AT40K20-2AJC
**8C1039A
**9846
Used clock = 40MHz

2. Used software:
**Atmel IDS 6.0
**Symplify (simulates the HDL design fine all the time)


Article: 18927
Subject: Re: Programming Virtex device via JTAG
From: Michael Schmid <mlschmid@iis.fhg.de>
Date: Mon, 22 Nov 1999 10:25:47 +0000
Links: << >>  << T >>  << A >>
Tom McLaughlin wrote:
>
> Well, I guess no one has done this???  I've read all the docs I can get my
> hands on and I think I'm doing everything right.  However, the Xilinx doc
> says that INIT must have a pulldown to ground on it to be able to program
> the device through the JTAG TAP.  The test board we have has a pullup to
> Vcc on INIT. Is this my problem???
>
> The tools say that the bitstream loads, but the DONE led never goes off and
> the FPGA does not function.
>
> Any help would be appreciated.
>
> Tom
>
> > I have a development board from VCC that has a Virtex XCV300 onboard.
> > It can be configured through a flash PROM, a multilink cable, an
> > xchecker cable and a JTAG port.  I am trying to configure it via the
> > JTAG port so we can learn how this works for our system.
> >

Hi Tom,

We'v done JTAG configuration of virtex
XCV300 with  XChecker and also with a
(Application Note Xilinx). There were no
problems. I think the pullup on init is
ok (we have the same).
I will tell you the other configuration
pins for orientation:

M0,M1,M2 = GND (seriell Master for PROM
Configuration)
#PROGRAM = Reset-Generator with high
after 100ms (for PROM Configuration)
#INIT = Pullup with 6k8
TMS = 	TMS(XChecker)
TDI = 	TDI(Xchecker)
TCK = 	TCK(XChecker)
TDO = 	RD(XChecker)
VCC(XChecker) = 3,3V
GND(XChecker) = GND

PS: We use the 3,3V-Adapter for
XChecker.

For more help try the Xapp138 and
Xapp139 at Xilinx.

Good luck,

Michael

mlschmid@iis.fhg.de

Article: 18928
From: chiuj@aol.com (Chiuj)
Date: 22 Nov 1999 11:10:29 GMT
Links: << >>  << T >>  << A >>
Protel does not require a key (dongle).  This alone is better than the rest.
If you are not doing 10 layer PC mother boards running in the terahertzs,
Protel schematic is a good package for the front end.  PADs is bit better on
the layout  side when compared to Protel PCB 2.8.  Have not used version 3.0.

hope this helps ,
jc

Article: 18929
Subject: Hierarchical Scan Insertion
From: "Duck Foot" <duckfoot11@hotmail.com>
Date: Mon, 22 Nov 1999 11:31:52 GMT
Links: << >>  << T >>  << A >>
Hi,
I'm working on scan insertion with synopsys Test-compiler.
The design is about 80,000 gate large, and consists of a few submodules.
Since direct scan insertion on top module of the design takes too much time
in fixing fan-out rule cost, I need to insert scan submodule by submodule
and just link them on top module.

There exists my problem that the submodule "does not receive clock pulse"!!!
If I set "existing_scan" to false, the error is not reported, but when it's
set to true "check_test" sends me TEST-516 error.

The design itself does not have test rule violation, and has been already
test-compiled with over 99% fault coverage.

I hope somebody shed light on me.


Article: 18930
Subject: Re: Altera JAM
From: steve (Steve Rencontre)
Date: Mon, 22 Nov 1999 13:09 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <gDXZ3.34919$YI2.1673968@typ11.nn.bcandid.com>, ewagner@pdq.net (Erich Wagner) wrote: > Is anyone actively using Altera's JAM technology? What are your > experiences? > I haven't heard anything about it for over a year and had assumed > (probably > incorrectly) that interest in it had faded away. My experience with Altera devices has been the Flex and Max ranges. The former don't need complex programming, you just download the bitstream, and the latter I use where I specifically /don't/ need field upgradability. A typical application uses a Max device to get just enough of the system running to configure the Flex device(s) which do the real work. It's programmed once, with MaxPlusII on the desktop or a production programmer, and then doesn't change. JAM solves a problem I've never had: in-service reprogramming of devices with complex algorithms where no PC is available. My last experience of JAM was earlier this year, when I had a client struggling with it. The solution didn't use JAM :-) That said, I can certainly see uses for it, just not in situations I've been in personally. -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.uk  Article: 18931 Subject: Re: Virtex: Getting flip-flops into the pads From: John F Gostomski <jfg@nospam.com> Date: Mon, 22 Nov 1999 13:31:33 GMT Links: << >> << T >> << A >>  Also, watch out for replicated flip-flops from Synplify. Even with map -pr b, you still may have inputs/outputs registered within the clb's. simon_bacon@my-deja.com wrote: > Looking in the .MRP file (from MAP) is much easier than lurching > around in FPGA Editor. > Also, beware that Synplify is 'smart' enough to convert some register > sequences to SRLs, which can _never_ be put into IOBs. When this > happens you have to dance the attribute tango, or use explicit > FF instantiation, to get the result you desire. > In article <814j3o$6ai$1@bcrkh13.ca.nortel.com>, > "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: > <snip> >> I've checked this using the FPGA editor. The pads are only being >> used as IBUF or OBUF. > Sent via Deja.com http://www.deja.com/ > Before you buy.  Article: 18932 Subject: Re: Why not Lucent ORCA FGPAs? From: a@z.com Date: Mon, 22 Nov 1999 09:06:27 -0500 Links: << >> << T >> << A >> Hi Ray, Let me subscribe to your opinion. The EPIC design editor (of Neocad origin) was common to the ORCA NeoCAD Foundry and Xilinx M1.x tools. The bugs were common too! In fact I know a number of very obvious UI bugs that I discovered in the NeoCAD EPIC in the early nineties that were still present last year in the M1.5 EPIC. The tool crashed so often that it even had a crash recovery mechanism in place. But the crash recovery mechanism, that was recording all your commands during the previous session and replaying them in the new session also had a bug - it replayed the last command too so the program crashed again - and you had to manualy delete the last comand from the command history file. It was OK for viewing the design but completely useless as an editor. The M2.1 design editor doesn't crash as much but saving your work often is still a good idea. I have never seen the XACT XDE crashing and the user interface was also better. Catalin Ray Andraka wrote: > EPIC is _NOT_ a floorplanner. It is an editor, and a PITA at that. I'd take the > old the Xact 6.0 XDE and floorplanner over the current tools any day if they > would support the current devices. > > Adam J. Elbirt wrote: > > > Just as an FYI, Lucent has had the EPIC floorplanner for quite some time. In > > fact, they had EPIC before Xilinx had their M1 equivalent. > > > > Adam > > > > -- > -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: 18933 Subject: Re: PADS Experience? From: Theron Hicks <hicksthe@egr.msu.edu> Date: Mon, 22 Nov 1999 09:27:33 -0500 Links: << >> << T >> << A >> Anthony, I am using the PADS package and I am quite pleased with it. I have been using it for about 3 or 4 years. It is the only package of this type I have ever used. The user interface started out as quite obvious. As the complexity of the package has grown the interface has, of necessity, become less obvious. User Support: Response tends to be about 24 hours (1 business day) or less. Sometimes the response is immediate but usually I need to leave a message and they me call back. I bought my package through a PADS reseller ( CircuitCAD - 937-434-5127 - http://www.circuitcad.com/. I am in Michigan. They happen to be out of Dayton, Ohio.) CircuitCAD has been very helpful and often they can give me the help directly. When they can't they also have a little better pull at PADS to get very fast support. Usually that is not really necessary. Paid support updates: Worth their weigth in gold. The updates are not just bug fixes. They tend to be MAJOR improvements/extensions in the product. Hierarchical support: I have only just begun to use the Hierarchical blocks but they seem to be pretty well done and easy to use. Spectra - autorouter: The Spectra Router is less than perfect. It works fine for non-critical tasks but you have to watch for screw-ups in planes, etc. By that I mean it crossed over some of my split ground planes and then back. In all fairness, I purchased only the lowest priced version. Component auto-placement: Absolutely worthless in my work. Again, see the note above. Good luck, Theron Hicks Anthony Ellis - LogicWorks wrote: > Sorry. Thids is not an FPGA question but I am sure you all use similar > tools. > > Has anyone any comment on the PADS schematic capture tool as compared to say > Orcad or Protel. > I am looking for a good, reasonable cost, front end for PCB designs - > Win85/98 based. > Someting with good hierarchy support rather than "dumb" busses and blocks. > > Anthony > -- > LogicWorks - Electronic Development Services > Anthony Ellis > Cell: 082 4453285 > Phone 27-(0)12 9988062  Article: 18934 Subject: Re: Why not Lucent ORCA FGPAs? From: husby@fnal.gov (Don Husby) Date: Mon, 22 Nov 1999 14:40:03 GMT Links: << >> << T >> << A >> > I am not clear about saying the software doesn't support the "flexible" > carry chain. I have done a bit of testing with counters and such and > found that I can place them not only vertical or horizontal, but around > corners! The only requirement for carry chains is to keep the PLCs > adjacent. I assume that you mean the synthesis software doesn't use this > feature? The Xilinx 4000 parts allow you to program the carry function independently from the LUT. This made it possible to implement non-standard functions such as a rotating priority selector. This has been eliminated in Virtex. However, it looks like Lucent has added it to the OR3T architecture. From their documentation (page 17 of the June99 data sheet) it seems that both the carry and function bits are partially programmable via the LUT. The only problem is that the software doesn't give you access to this feature. I agree that schematics are still the best way to enter a design. I just thought I would beat my head against the VHDL wall one more time before going back to schematics. -- 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: 18935 Subject: Re: Why not Lucent ORCA FGPAs? From: husby@fnal.gov (Don Husby) Date: Mon, 22 Nov 1999 14:52:58 GMT Links: << >> << T >> << A >> Robert Sefton <rsefton@home.com> wrote: > I'm a long-time Xilinx user but have been using Orca for the past > year due to circumstances beyond my control. My overall opinion of > the 3T and 3L devices is positive, but there many other reasons to > choose Xilinx over Orca: > ... All are valid points. Lucent should pay attention. It appears that Lucent has started to put more effort in to their software in the past year. Maybe something good will come from it. Lucent could also use a little help with marketing. Their new chips seem to arrive quietly on the scene while Xilinx's and Altera's are preceeded by many months of fanfare. -- 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: 18936 Subject: Re: Virtex: Getting flip-flops into the pads From: "Jamie Sanderson" <jamie@nortelnetworks.com> Date: Mon, 22 Nov 1999 10:51:10 -0500 Links: << >> << T >> << A >> First of all, my thanks to everyone who replied here and by e-mail. I was able to get the flip-flops into the pads by using the implementation option in Design Manager. I believe this is equivalent to the "map -pr" command-line options. What still puzzles me is that I didn't need to do this with the XC4000 series. The technology view for my designs clearly shows that it used the registered I/O primitives (IFD, OFD, etc.). Regardless of the "map" options, the Xilinx tools would respect that. It is troubling that I now have to force the registers into the pads. Even with the "xc_ioff" attribute set to 1 or true in Synplify, the technology view reveals that it is only using IBUF or OBUF primitives. I would much rather the synthesis tool be responsible for the placement of the flip-flops, rather than Xilinx's mapper. Regards, Jamie Jamie Sanderson <jamie@nortelnetworks.com> wrote in message news:814j3o$6ai$1@bcrkh13.ca.nortel.com... > > Moving on to the bigger problem... Top-level signals which are registered > (either inputs or outputs) aren't being clocked in the pad. I've checked > this using the FPGA editor. The pads are only being used as IBUF or OBUF. > The registering of the signal occurs inside a CLB. What I want, and what > used to happen automatically, is for the register to reside in the pad. Fast > clock to output delays depend on this.  Article: 18937 Subject: Re: Altera JAM From: "Bernard Esteban" <esteban@worldnet.fr> Date: Mon, 22 Nov 1999 17:14:54 +0100 Links: << >> << T >> << A >>  Erich Wagner <ewagner@pdq.net> wrote in message news:gDXZ3.34919$YI2.1673968@typ11.nn.bcandid.com...
> Is anyone actively using Altera's JAM technology? What are your
experiences?
> I haven't heard anything about it for over a year and had assumed
(probably
>
> Thanks,
> Erich
>
>
>
I use JBI.EXE with ByteBlaster for six months, it works fine, it's used for
functional test.
On www.altera.com you can find the an088.pdf very usefull.

Bernard Esteban


Article: 18938
Subject: Re: Trouble with ATMEL's AT40K20
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Mon, 22 Nov 1999 09:28:44 -0700
Links: << >>  << T >>  << A >>
Filip S. Balan wrote in message <81b55i$q7v$1@strelovod.uni-mb.si>...
>I have the following problem:
>
>Even with a very simple design (cca. 500-bit shift register)
>I was unable to get a correct working FPGA. With a even
>more simpler design (cca. 128-bit shift register), that works
>fine on SOME cell locations I found out, that the INTIRE 1'st column
>of cells (and unfortunately some other cells/paths to) won't work.
>
>Damged FPGA's (series) , faulty software ...??
>Any similar problems?
>
>Filip S. Balan
>balan@uni-mb.si
>
>P.S.
>1. Chips:
>I have 4 chips, but all of them are working exactly equal - faulty :-((
>**AT40K20-2AJC
>**8C1039A
>**9846
>Used clock = 40MHz
>
>2. Used software:
>**Atmel IDS 6.0
>**Symplify (simulates the HDL design fine all the time)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Synplify is NOT a simulator.  You need to purchase a (V)HDL simulator tool
and prove that your logic is correct.

--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.


Article: 18939
Subject: Re: Why not Lucent ORCA FGPAs?
From: Robert Sefton <rsefton@home.com>
Date: Mon, 22 Nov 1999 17:15:29 GMT
Links: << >>  << T >>  << A >>
Rickman wrote:
>
> Robert Sefton wrote:
> >
> > 4. Xilinx has a much more clear and agressive road map going
> > forward. They're the clear technology leader in the FPGA space in
> > my opinion.
>
> I did not see a lot of difference in their products myself. Xilinx may
> talk about their future products more, but I just don't see much
> difference in their current products. The big reason I am using the Orca
> parts now is the difference in IO count for a given package. I consider
> this to be a significant reason to go with Lucent myself.

There are major issues with big I/O counts, nothing comes for
free. Current IC packaging and PCB technology makes it difficult
to provide adequate decoupling, signal isolation (crosstalk), and
termination (e.g., series resistors) with very dense I/O. Orca may
provide more pads, but can you safely use them all? Xilinx has
taken a more conservative (and safer) approach I think.

>
> Can you elaborate on why you feel Xilinx is the techology leader?

Some items off the top of my head:

1. I prefer the Virtex IOB structure. The Orca PIC ties four pads
together for clocking, CE, etc. This is not as flexible as Xilinx.
You really have to be conscious during board layout about where
you assign your I/O if you have more than one clock. And the
grouping is not the same from 3T to 3L for some packages (more
work required when laying out to support 3T and 3L devices).
2. The same can be said about the Orca PFU structure vs. Virtex
CLB. Too many common signals (e.g., one clock) in the PFU make the
architecture less flexible in my opinion.
3. Virtex supports a bunch of I/O standards. Orca supports TTL and
CMOS.
4. Virtex provides block RAM. Orca not.
4. Virtex is currently available in much higher gate counts.
5. Orca RAMs write data on the falling edge of the RAM clock. This
creates a nasty 1/2 cycle path through the read port. Not always
an issue, but has to be considered. The Virtex CLB RAM writes on
rising edge.
7. The Orca PCM (programmable clock manager) was unusable in 3T
(may have been a tool issue, I forget) and I assume the situation
hasn't changed in 3L. I know the Virtex DLLs work as advertised.

Don't get me wrong, Orca has a couple of advantages (none come to
mind, but I know they exist), but overall Xilinx has a big
technology edge in both devices and tools. It's been so long since
I looked at Altera I can't comment in detail, but Altera realy
competes in a different segment of the market in my opinion. They
appeal to a different type of user than Orca or Xilinx. But I know
the new Altera tools are having problems, and I didn't care for
the Same Frame concept (referred to as Lame Frame by some).

> > One other general comment. Xilinx's sole business is programmable
> > logic. FPGAs is a very small part of Lucent's business, and it
> > shows. If Lucent ever really threw significant development/support
> > and marketing resources at Orca I think they could almost compete
> > with Xilinx. But the commitment just isn't there. I think you
> > would be much happier and successful as a Xilinx customer.
>
> I don't know that I agree with this. I remember when I spoke with the
> Lucent people in the past, they seemed very committed to making their
> products competitive to Xilinx and others. If you speak with the FPGA
> group, they will be just as narrowly focused on FPGAs as anyone at
> Xilinx. Then there are a lot of people elsewhere in the company who are
> also supporters of the Orca FPGAs. I know because I am working with one
> on this project. My DSP programmer (midnight consulting) works for
> Lucent and is very excited about getting his hands dirty with their
> FPGAs.
>

I don't question the commitment of the FPGA group, I just question
how autonamous they are and how committed corporate management is
to becoming a leader in the FPGA market. I bet they'd have a much
better chance competing if Lucent spun them off.

Good luck with your project. I hope you do give some feedback on

RJS

Article: 18940
From: John Larkin <jjlarkin@highlandtechnologySnipThis.com>
Date: Mon, 22 Nov 1999 09:49:47 -0800
Links: << >>  << T >>  << A >>
On Mon, 22 Nov 1999 06:07:05 +0200, "Anthony Ellis - LogicWorks"
<a.ellis@logicworks.co.za> wrote:

>Sorry. Thids is not an FPGA question but I am sure you all use similar
>tools.
>
>Has anyone any comment on the PADS schematic capture tool as compared to say
>I am looking for a good, reasonable cost,  front end for PCB designs -
>Win85/98 based.
>Someting with good hierarchy support rather than "dumb" busses and blocks.
>
>
>Anthony

Anthony,

I've used a few schematic editors and prefer PADS. It's not just a drawing
program, it really understands that what we're drawing is a *schematic*. It
won't, for example, let you miss a connection by a couple of pixels, as many
packages will.

PADS Logic (the schematic thing) doesn't use a dongle, but the PC layout stuff
does.

John


Article: 18941
Subject: Filter Coeficent and output quantisation
From: ritchie99_uk@my-deja.com
Date: Mon, 22 Nov 1999 18:06:31 GMT
Links: << >>  << T >>  << A >>
Hi all,

Any orientation please concerning any valuable
reference ( books-papers) dealing with the effect
of Filter coefficient quantisation and the
truncation of the output results on the final
performance.

what effect will have the truncation at the
output of each multiplier comparing to the
truncation at the output of the filter on the
final PSNR, is there any mathematical
approach dealing with this subject.

I am getting problems to specify the optimal
internal wordlength of an FIR
, with fractional coefficients, taking into
account parrallel approach

best regards

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

Article: 18942
Subject: Filter Coefficient and Output Quantisation
From: ritchie99_uk@my-deja.com
Date: Mon, 22 Nov 1999 18:17:39 GMT
Links: << >>  << T >>  << A >>
Hi all

Any orientation please concerning any valuable reference ( books-
papers) dealing with the effect of Filter coefficient quantisation and
the truncation of the output results on the final performance.
what effect will have the truncation at the output of each multiplier
comparing to the truncation at the output of the filter on the final
PSNR, is there any mathematical approach dealing with this subject.
I am getting problems to specify the optimal internal wordlength of an
FIR , with fractional coefficients, taking into account parrallel
approach

best regards

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

Article: 18943
From: jhallen@world.std.com (Joseph H Allen)
Date: Mon, 22 Nov 1999 18:27:40 GMT
Links: << >>  << T >>  << A >>
In article <383952D5.A84E4F34@egr.msu.edu>,
Theron Hicks  <hicksthe@egr.msu.edu> wrote:

>Spectra - autorouter:
>    The Spectra Router is less than perfect.  It works fine for
>non-critical tasks but you have to watch for screw-ups in planes, etc.  By
>that I mean it crossed over some of my split ground planes and then back.
>In all fairness, I purchased only the lowest priced version.

There are a lot of games you can play even the cheap version, with just the
per-net via costs, routing priorities and locked nets.  For example, I
limited the ECL section of a high speed board to a single plane. I bet there
is some way to make it more plane aware- someday I'm going to investigate
the PADS/Specctra conversion process more closely.

The four layer version starts out at $2000 or something, and there are something like 6 other options you can buy. They key one which allows you to specify maximum delay values on each net (I think it's called the high-speed option) is the most expensive,$8000 on top of the basic price.

But then, PADS itself knows about signal delays, so you can check or
preroute critical signals by hand.
--
/*  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: 18944
Subject: Re: Why not Lucent ORCA FGPAs?
From: Ray Andraka <randraka@ids.net>
Date: Mon, 22 Nov 1999 13:36:12 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:

> > I am not clear about saying the software doesn't support the "flexible"
> > carry chain. I have done a bit of testing with counters and such and
> > found that I can place them not only vertical or horizontal, but around
> > corners! The only requirement for carry chains is to keep the PLCs
> > adjacent. I assume that you mean the synthesis software doesn't use this
> > feature?
>
> The Xilinx 4000 parts allow you to program the carry function independently
> from the LUT.  This made it possible to implement non-standard functions
> such as a rotating priority selector.  This has been eliminated in Virtex.
>

No kidding.  Xilinx, for the most part doesn't see the problem.  Then again,
they think all the carry chain is good for is add, subtract, increment and
decrement.  It was bad enough when they took away the bidirectional carry chain
in the 4KE parts - it hurts to turn the bus upside down to do a first one's
detect.

> However, it looks like Lucent has added it to the OR3T architecture.  From
> their documentation (page 17 of the June99 data sheet) it seems that both
> the carry and function bits are partially programmable via the LUT.  The
> only problem is that the software doesn't give you access to this feature.
>
> I agree that schematics are still the best way to enter a design.  I just
> thought I would beat my head against the VHDL wall one more time before
> going back to schematics.

I've been using, no beating my head against the wall, with VHDL lately too.
I'm doing it for two reasons: First I have some customers who bought the VHDL
thing hook, line, and sinker (try to convince them they're wrong!), and for my
own stuff because it allows me to parameterize functions pretty easily.  I'm
beginning to wonder if I'll ever see the return on the design investment for
those parameterized thingies though.

--
-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: 18945
Subject: Re: Filter Coefficient and Output Quantisation
From: jhallen@world.std.com (Joseph H Allen)
Date: Mon, 22 Nov 1999 19:03:25 GMT
Links: << >>  << T >>  << A >>
In article <81c1bt$ank$1@nnrp1.deja.com>,  <ritchie99_uk@my-deja.com> wrote:
>Hi all

>Any orientation please concerning any valuable reference ( books-
>papers) dealing with the effect of Filter coefficient quantisation and
>the truncation of the output results on the final performance.

I do not have a reference, but I suggest you try to find a book on numerical
analysis.  There are very thorough equations which address this problem,
traditionally to handle floating point rounding.  I bet this raises
stability issues with recursive filters...

--
/*  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: 18946
Subject: Re: Why not Lucent ORCA FGPAs?
From: jhallen@world.std.com (Joseph H Allen)
Date: Mon, 22 Nov 1999 19:11:27 GMT
Links: << >>  << T >>  << A >>
In article <38398D1C.A7B9E445@ids.net>, Ray Andraka  <randraka@ids.net> wrote:
>Don Husby wrote:

>> I agree that schematics are still the best way to enter a design.  I just
>> thought I would beat my head against the VHDL wall one more time before
>> going back to schematics.

>I've been using, no beating my head against the wall, with VHDL lately too.
>I'm doing it for two reasons: First I have some customers who bought the
>VHDL thing hook, line, and sinker (try to convince them they're wrong!),
>and for my own stuff because it allows me to parameterize functions pretty
>easily.  I'm beginning to wonder if I'll ever see the return on the design
>investment for those parameterized thingies though.

It is a similar situation to templates in C++.  You get all of theoretical
resuse- but usually only for the simplest of algorithms.  In the end you
waste a lot of time writing a confusing template for an algorithm for which
you only need a single instance of anyway.

I think VHDL is probably better than schematics for large team-based
designs, however.  Documentation and verification is more automatic.
--
/*  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: 18947
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Mon, 22 Nov 1999 11:18:44 -0800
Links: << >>  << T >>  << A >>
Re PADs Power logic schematic
Cons:
- The "hierarchy" feature provided is a cruel joke -
it bears no resemblence to a real hierarchical schematic tool
- All labeled nets are GLOBAL - no local sheet nets
- No bus pins on symbols
- Very tedious part attribute editing, label positioning
- No way to paste schematic sections into Windows documents

Pros:
- Cheap, works O.K. as PADS PCB front end for simple designs, but that's about it.

regards, tom

Anthony Ellis - LogicWorks wrote:
>
> Sorry. Thids is not an FPGA question but I am sure you all use similar
> tools.
>
> Has anyone any comment on the PADS schematic capture tool as compared to say
> I am looking for a good, reasonable cost,  front end for PCB designs -
> Win85/98 based.
> Someting with good hierarchy support rather than "dumb" busses and blocks.
>
> Anthony
> --
> LogicWorks - Electronic Development Services
>     Anthony Ellis
>     Cell:           082 4453285
>     Phone      27-(0)12 9988062

--
Tom Burgess
--
Digital Engineer
P.O. Box 248, Penticton, B.C.

Article: 18948
Subject: Re: configure_flex10k30e_jtag_jam
From: a_maier@my-deja.com
Date: Mon, 22 Nov 1999 20:55:49 GMT
Links: << >>  << T >>  << A >>
In article <38387F54.C0FBEA11@magtech.com.au>,
Michael Stanton
<mikes@magtech.com.au> wrote:
> Andreas
>
> Sorry if this sounds dumb, but
check the actions in the parameters you pass when
> you call jam.exe.
> Jam
will happily do nothing (without complaint) if you don't include something
>
like "DOCONFIGURE=1" with the parameters in the call.
>
> We use the Jam
player to configure a 10K30A as part of a 3 device JTAG chain,
> through an
"embedded" ByteBlaster and it has been working fine so far...
>
> Regards,
Michael
>
Hello Michael

that if one uses JAM/STAPL
instead of JAM version 1.x the parameter is
"-ddoconfigure=1"; second problem was, that even
the Application Engineer from
Altera didnt know this... ( i am in contact
with the App. Engineers of my Distributor
here in Germany and with Altera
directly)
Further problem is, that i couldnt get the DOS version of the
JAM-player to run.
I did some customization (other port io) but this works
fine if i use the
windows-version (running under WIN95/98). Seems to be a
memory problem
(like Steve Rencontre posted here - thank you Steve) but i
have only one device
to configure and the file size is about 35k (JAM1.1) or
45k(JAM/STAPL). Which
player do you use and what is the file size?

regards
Andreas

> a_maier@my-deja.com wrote:
>
> > Hello All i want to configure a
altera flex10k30e using the jtag-port and a
> > jam-player. I am using MAX+II
vers. 9.30 and the update to 9.31 applied to
> > it. The jam-player i ported
for my hardware is vers. 2.12. When running the
> > JAM/STAPL file of my
design an error occurs (even with the original 16bit
> > jam-player jam.exe).
> > Is there anybody
who has experience in configuring flex devices with JAM?
> >
> > Andreas
> >
> > Sent via Deja.com http://www.deja.com/
>
>

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

Article: 18949
Subject: Re: Altera JAM
From: a_maier@my-deja.com
Date: Mon, 22 Nov 1999 21:05:09 GMT
Links: << >>  << T >>  << A >>
In article <gDXZ3.34919\$YI2.1673968@typ11.nn.bcandid.com>,
"Erich Wagner" <ewagner@pdq.net> wrote:
> Is anyone actively using Altera's JAM technology? What are your experiences?
> I haven't heard anything about it for over a year and had assumed (probably
>
> Thanks,
> Erich
>
Hello Erich

I am using JAM/STAPL (= version 2.x) and try to use the JAM-player vers. 2.12.

regards Andreas

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