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

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

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

Custom Search

Messages from 56300

Article: 56300
Subject: Re: Xilinx : BEL constraint vs. ModelSim
From: Ray Andraka <ray@andraka.com>
Date: Mon, 02 Jun 2003 20:09:42 GMT
Links: << >>  << T >>  << A >>
I've had the same trouble with modelsim and  'BEL' if it is
not declared in the architecture where it is used.  Never
got to the bottom of why it was no good in a package.
Declare it locally and it should be OK.

Stewart Cobb wrote:

> I've been trying to construct some RPM's in VHDL (thanks
> to Ray Andraka for inspiration!).
>
> The problem I'm having comes when I try to do a functional
> simulation in ModelSim.
> ModelSim doesn't like the "BEL" constraint. I get errors
> like the following:
>
> # WARNING[10]: m2s.vhd(139): Making two objects with the
> name "bel" directly visible via use clauses results in a
> conflict, neither object is made directly visible.(LRM
> Section 10.4)
> # ERROR: m2s.vhd(139): Attribute bel has not been
> declared.
>
> The line numbers refer to lines like this:
>
> attribute BEL of m2s_LUT : label is bel_luts(bel_i);
>
> What I /think/ is going on is that the attribute name
> "BEL" conflicts with name of the character 'bel' (seventh
> character in the enumerated type "character").
> Type "character" is part of the "std" library which is (by
> definition!) always loaded.
> I would think these names should be in separate
> namespaces, but ModelSim apparently thinks otherwise, and
> quotes the VHDL Language Reference Manual ("LRM Section
> 10.4") in its error message to prove its point.
>
> Xilinx XST seems to treat these as
> separate namespaces, and doesn't notice a conflict.
>
> So what can I do about this?
>
> I can't rename the attribute, because then the Xilinx
> mapper won't recognize the constraint.
>
> I could move the BEL constraint from the VHDL source to a
> UCF file -- but I've been trying very very hard to move
> all the constraints to VHDL for portability, and that
> would be a step backwards.
>
> I can't rename the character 'bel',
> because it's part of the IEEE standard (and probably a
> mil-spec to boot). It's also the historic ASCII name for
> that character, and changing it would confuse a lot of
> people.
>
> I can give up functional simulation, and just rely on
> post-PAR simulation. I'd rather not do that, because I'm
> depending on functional simulation to debug some of my
> more complex RPM macros, which disappear after synthesis.
>
> If the problem were with XST and not Modelsim, I could
> surround the offending lines with "-- synthesis
> translate_off" constructs. But instead I have lines that
> XST needs to see and ModelSim needs to ignore. Is there a
> "-- modelsim translate_off" construct?
>
> The best solution I can think of is for Xilinx to provide
> an additional constraint named, say, "XBEL", that works
> the same way as the existing BEL constraint. But for that,
> I'd have to wait for Xilinx to agree and then implement
> it.
>
> Any suggestions for what to do in the meantime?
>
> Cheers!
> --Stu

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin
Franklin, 1759



Article: 56301
Subject: Re: Xilinx : BEL constraint vs. ModelSim
From: "Stewart Cobb" <nospam@nospam.org>
Date: Mon, 2 Jun 2003 13:58:46 -0700
Links: << >>  << T >>  << A >>
Thanks, Ray! That did it. 

I guess the problem is that "things" in packages are defined (LRM) to share a namespace, but "things" in individual files have a different namespace. Odd, but that seems to be the way it works. 

Thanks again for the tip. 

Cheers! 
--Stu 


Article: 56302
Subject: Re: power consumption in CMOS..
From: Brian <usenet@carlsonclan.com>
Date: Mon, 02 Jun 2003 17:07:22 -0400
Links: << >>  << T >>  << A >>
On Mon, 02 Jun 2003 10:48:53 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>And please no jokes about the California power crisis of 2 years ago.
>That was not due to lack of power, but due to greedy
>managers/manipulators and stupid politicians...

No, that was due to stupid enviromentalists who would rather have mice
than air conditioning and cold beer ;)


Article: 56303
Subject: Re: FPGA design: firmware or hardware?
From: JoeG <no@where.net>
Date: Mon, 2 Jun 2003 21:16:02 GMT
Links: << >>  << T >>  << A >>
We classify it as both hardware(FPGA itself and associated gates) and software(VHDL
level listing and programming data stream)

Joe Gallegos

Ray Andraka wrote:

> Perhaps, but it is different from the more traditional software in that there
> are concurrency and timing issues that do not apply for traditional software.
> The design flow is hardware, the result is perhaps software.  For that reason,
> it does make sense to differentiate it.  I am constantly fighting the problems
> introduced by people treating the FPGA contents as software when they do their
> designs, and we see a fair amount of the results of that mentality here too.  If
> for no other reason than to avoid that leap, I think it is prudent to call it
> something other than software.
>
> Steve Casselman wrote:
>
> > I have always called it software. Since 1986. FPGAs are a kind of computer
> > chip with a very strange programming model. The programming model was
> > created by hardware engineers who were concerned about current spikes during
> > programming. They were not concerned about reprogramming the device so much
> > as just programming it the first time. They did not really care about
> > programming parts of the device although that is starting to become more
> > important as you get really large devices with embedded processors and
> > internal programming ports.
> >
> > In the end it is software. It is based on sram it is updatable at any time.
> > It can be stored on a disk or delievered over a network.
> >
> > It is software..
> >
> > Steve
> >
> > "Joe Frese" <joefrese@hotmail.com> wrote in message
> > news:c176b8c2.0305211126.6e642649@posting.google.com...
> > > I've got a question of terminology for the group: is FPGA design
> > > generally classified as hardware, firmware, or neither?  Most of the
> > > designs I've worked on have served to interface firmware with
> > > hardware.  It seems that firmware engineers like to think of FPGA
> > > designs as more firmware, and that hardware engineers like to think of
> > > FPGA designs as more hardware.  As an FPGA developer, though, I'm of
> > > the mind that the unique design considerations of the technology
> > > justify a new and separate category . . .
> > >
> > > A coworker suggested the term "coreware," but apparently that's a
> > > registered trademark of LSI Logic.  Is there another term with the
> > > -ware suffix commonly used to refer to code (VHDL, Verilog, or
> > > otherwise) intended to be implemented in an FPGA?
> > >
> > > Joe
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 56304
Subject: Re: HDLmaker update available
From: jaxlau@yahoo.com (Jacques athow)
Date: 2 Jun 2003 14:24:11 -0700
Links: << >>  << T >>  << A >>
"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message news:<pan.2003.06.02.18.57.46.805141.2430@polybus.com>...
> ModelSim support has returned to HDLmaker as of version 6.6.1. HDLmaker is
> an open source Verilog/VHDL hierarchical code generator for FPGAs and
> ASICs.
> 
> HDLmaker is available free of charge from Polybus Systems at
> 
> http://www.polybus.com/hdlmaker/users_guide/

I just checked this website and found out that it supports the Xilinx
XC4000e series. Does this implies that I will be able to synthesize my
old design and use the Free Xilinx implementation tool complete the
process?

Jacques

Article: 56305
Subject: Re: I want a 800 k gates FPGA in 40 pin DIL
From: JoeG <no@where.net>
Date: Mon, 2 Jun 2003 21:29:36 GMT
Links: << >>  << T >>  << A >>
Still a dead issue -- Even at 1 Mhz edge speeds will remain a problem -- the
key is 'edge' speeds

Rene Tschaggelar wrote:

> At 10MHz clock the thing would be technically doable.
> The original poster never mentioned the usual 200MHz+.
> A do-your-own 68000 cpu kind of.
>
> Rene
>
> Peter Alfke wrote:
> > Let's look at this from the inside out.
> > Your 800k-gate FPGA chip will measure about 7 x 7 mm. (I remember that
> > the XC2V6000 die is about 21 x 21 mm, and you want about 8 times less in
> > area, about 3 times less on each side. We can argue about gate count
> > metrics, but this will be close.)
> > If you stuff this little chip of less than 300 mil on-a-side into a big
> > 40-pin package with  600 mil width, 100 mil pin spacing, and 2 inch
> > total length, (I remember those things well) you inevitably end up with
> > some very long bonding wires or lead-frame metal runs, once you get away
> > from the nice central pins (which should be dedicated to Vcc and ground)
> > The worst wires will be an inch or even 30 mm long, and their inductance
> > will be totally unacceptable for modern fast output transitions. And
> > don't even mention wire-wrap...
> >
> > So, the 40-pin DIP is a dead issue for modern circuits, even if FPGA
> > vendors wanted to cater to the small market for very low
> > pin-to-logic-ratio devices.


Article: 56306
Subject: Re: Need help with Xilinx ISE
From: JoeG <no@where.net>
Date: Mon, 2 Jun 2003 21:41:28 GMT
Links: << >>  << T >>  << A >>
For Peter Alfke et.al.

I have an issue with Xilinx dropping support on their new tools on legacy devices
-- For example Xilinx continues to offer militarized XC4005 devices but their
current  ISE s/w does NOT support these devices(ie. routing). Hence, one is
forced to used the old XACT(crica 1990's) tool set. What's up?

Ray Andraka wrote:

> Hmm,   Not sure you can get it anymore if you don't already have it.  Ask
> your FAE for a copy.  No, I don't believe 5.2 supports the Spartan I's.  The
> problem with 4.2's router is it makes every path a critical path, so although
> you can see which path(s) fail timing, fixing those may not fix the
> underlying problem.
>
> email_address@message.end wrote:
>
> > Ray,
> >
> > What is v3.3sp8, and how do I get it?
> >
> > I can't use ISE-5.2 with a 5V Spartan, can I?
> >
> > Thanks,
> > Gary.
> >
> > On Sun, 01 Jun 2003 21:59:04 GMT, Ray Andraka <ray@andraka.com> wrote:
> >
> > >Use v3.3 sp8 instead.  The router in 4.x is lazy.  FWIW, I've had some
> > >good results so far with 5.2 sp3.  Seems Xilinx has fixed many of the
> > >problems I saw with the 4.2 router (Thank you).
> > >
> > >email_address@message.end wrote:
> > >
> > >> Hi all,
> > >>
> > >> Xilinx ISE is giving me fits.  I could swear that it hates me!  This
> > >> is version 4.2i, by the way.  Version 5 does not support the part I'm
> > >> using.
> > >>
> > >> Here's what's happening:
> > >>
> > >> The design is very close to -not- meeting the speed requirement, which
> > >> is 50 MHz.
> > >>
> > >> If, when ISE runs, it does 'improving timing' passes, the speed comes
> > >> out at 50.314 MHz.  If it does not run these passes, I get 47.246
> > >>
> > >> The problem is, I can't figure out how to get it to run these passes!
> > >> Some times it does, some times it doesn't.  The help file tells me to
> > >> check an option box, but that box doesn't exist!
> > >>
> > >> Please, how do I turn this option on?  Right now, ISE is stuck in the
> > >> mode where it does not run these cleanup passes.  :(
> > >>
> > >> And, if someone has a tutorial-like document for guiding place and
> > >> route, I would like to see it.  Basically, I want to 'suggest' to P&R
> > >> that certain (Verilog) modules belong in certain haves of the chip.
> > >>
> > >> Much Appreciated,
> > >> Gary
> > >> gwhelbig-at-yahoo-dot-com
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 56307
Subject: Re: FPGA's an Flash
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Jun 2003 10:10:23 +1200
Links: << >>  << T >>  << A >>
jetmarc wrote:
> 
> > The other problem, is that a little flash ram is not so little: 2.5
> > Mbytes.
> 
> Why don't FPGA chips support compressed bitstreams?

Some do.
 
> I recently did a such a thing in software (on a self-reconfiguring SoC).
> The original bitstreams were in the range of 500 kbytes, and compressed
> down to only 16-25 kbytes.  I left out all framing information and then
> used LZ77 and Huffman encoding.  About 200 bytes of assembler code are
> necessary to reconstruct the original bitstream.

 20:1 sounds very high compression, esp of 'design' not 'empty' FPGA.
 
> Now that FPGAs even DES-encrypt their bitstreams, one should really
> think they have enough resources to support compression, too!

 We did some trials with Run Length Encoding, which has very low silicon
cost,
and compressions at the low end of the scale, but still usefull.

 A FPGA vendor could take a more focused path (Skewed RLE), plus 
take some bitstream care to further assist compression 
- but it's all engineering time, and also likely to affect release
schedules.

-jg

Article: 56308
Subject: Re: FPGA's an Flash
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Jun 2003 10:21:14 +1200
Links: << >>  << T >>  << A >>
Peter Wallace wrote:
> 
> The SST 45LF010 (1Mb) has an all ones read command so it will connect with
> only one inverter as glue, alas it is the last of it kind, the later (and
> larger) 25 series parts have an 03 (ISTR) read command so they need a
> $.80 PIC or tiny CPLD helper, still cheaper than anything from X or A...
> 
Markus Meng wrote:
> 
> That's the way it is. I am jst wondering why SST or ST or others do not jump
> on this train by simply changing the command for the read array mode to
> something like all '0' and all '1'.

 They would not CHANGE the command, but there is certainly a 
'glaringly obvious' case for an ALIAS code of all 1's to 
start a Read-all.
 Besides system loaders, there are other applications that would
benefit from clock-only dump of the serial memory - trivial silicon
cost, for a bigger market footprint.

 Send an email to SST/ST/Atmel to suggest it !

-jg

Article: 56309
Subject: Re: New version,Low Speed
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 03 Jun 2003 10:46:28 +1200
Links: << >>  << T >>  << A >>
Paul Leventis wrote:
> 
> > Just my $0.02 worth.  I did a project using MaxPlus2 a couple years
> > ago.  We were pushing density on a 10K100A part and also needed speed on
> > a portion of it.  We found that the placement the tools were using could
> > not be understood by us.  When we tried using constraints, we found that
> > as often as not, we were working against the tool rather than helping
> > it.  So constraints are not an easy tool to use effectively.
> 
> It is hard to improve the push-button placement results through constraints,
> and I'm pretty sure it's impossible to beat the router's results.  For 10K
> and 20K, applying region constraints can help, as a human can sometimes
> figure out how to partition their design to fit the hard routing hiearchy
> boundaries in these parts better than the placer.  In the case of Stratix
> and Cyclone, it is much harder since there are no longer any hard
> boundaries.  For very regular/datapath designs (hi Ray) with short critical
> paths, relative placement constraints can still be beneficial.
> 
> Many times that users experience optimization success through the
> application of placement constraints, this is purely due to random noise --
> if the placer seed is swept across the before- and after-designs, any
> advantage often disappears.  This is a good thing... it means that
> push-button compile is doing a good job.
> 
> Note: The application of placement and routing back-annotation in order to
> preserve the performance of a previously successful fit is still _very_
> valuable in many designs.  It allows one to move a design from one version
> of Quartus to another, or to make small changes to a design without
> affecting the rest of it.

 Not to mention the important version control, and even EMC 
approval, issues.

 This 'statistical nature' of 'similar-but-not-the-same' results has
to be a real concern to the 'engineering' side of design.

 I can imagine it would get interesting explaining this to a ISO-9001
consultant, or even a large companies quality manager.

-jg

Article: 56310
Subject: Re: Virtex 2 evaluation board
From: billh40@aol.com (Bill Hanna)
Date: 2 Jun 2003 16:20:08 -0700
Links: << >>  << T >>  << A >>
"Bram van de Kerkhof" <bvdknospam@oce.nl> wrote in message news:<1054561920.762580@news-ext.oce.nl>...
> Hello,
> 
> I'm looking for an evaluation board of the Virtex 2 (actually for the
> Spartan 3 but as there are none available i will have to verify on the
> Virtex 2)
> I want to verify a ddr-sdram and 300 Mb's lvds  link design. Two avaluation
> boards is also ok (one for ddr and one for lvds).
> 
> Who has some idea's ?
> 
> Yours Bram
> 
> --
> ==================================================
> Bram van de Kerkhof
> 
> OCE-Technologies BV
> Building 3N38
> 
> St. Urbanusweg 43,
> Venlo, The Netherlands
> P.O. Box 101, 5900 MA Venlo
> ==================================================
> Direct dial : +31-77-359 2148
> Fax           : +31-77-359 5473
> ==================================================
> e-mail       : mailto:bvdk@oce.nl
> ==================================================
> www        : http://www.oce.nl/
> ==================================================

   AVNET has a Virtex 2 evaluation board kit (XC2V1500) that costs
$1,000.
I have purchased the XC2V4000 board kit ($2,500).  I have had problems
programming the XC2V4000 board MCM module  ( Flash Module), but they
are Xilinx software problems.  The board is well designed and works
OK.  It includes a DDR-SDRAM interface to a PCI bus.  I did not use
the DDR SDRAM or the PCI bus.  I did interface the AVNET 857T board to
the AVNET XC2V4000 board.

   The Memec board may be less trouble due to use of the configuration
PROMs.

Bill Hanna

Article: 56311
(removed)


Article: 56312
Subject: Level Converters
From: "Ed Stevens" <ed@stevens8436.fslife.co.uk>
Date: Mon, 2 Jun 2003 18:32:05 -0700
Links: << >>  << T >>  << A >>
Hi,

Does anyone know of any bidirectional 5V to 3.3V level converters?

Thanks,



Article: 56313
Subject: Re: JTAG madness
From: "KG7HF" <KG7HF@amsat.org>
Date: Tue, 03 Jun 2003 01:47:03 GMT
Links: << >>  << T >>  << A >>
ADI Sharc processors (8 - 21065s), Xilinx FGPA.  ADI tools to talk to the
Sharcs.  I didn't do any work with the FPGA so I can not comment on the FPGA
tools.



"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3EDA52FC.138FC0B2@yahoo.com...
> KG7HF wrote:
> >
> > Generally, it's OK to put various devices in a single chain.  You simply
> > have to use a configuration tool to describe the JTAG chain to the
debugger
> > so that it knows where the device you are trying to debug lies in the
chain.
> > Part of the description is the number of devices, and the size in bits
of
> > the instruction register.    The debugger will ignore all the other
devices
> > by using the bypass instruction and placing them in bypass mode.  This
> > allows the debugger to "focus" on the device in the chain you are trying
to
> > debug.
>
> What devices have you used in a scan chain together?  What tools did you
> use to talk to these devices?
>
>
> --
>
> Rick "rickman" 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      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 56314
Subject: Re: Xilinx Spartan download with Parallel III cable
From: "David Kinsell" <kinsell@poboxyz.com>
Date: Tue, 03 Jun 2003 02:49:14 GMT
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0305270412.307530aa@posting.google.com...
> Hi
>
> latest Xilinx iMpact doesnt seem to support the old style Parallel III
> cable any more, and it seems there is no way to get the bitstream
> into Spartan - the iMpact generated STAPL file does not work with JAM
> player 2.3 gives bound error.
>
> We just received some Spartan II evaluation boards only to find out that
> there are no means to get them configured.
>

I've got a Spartan II part on a PCI eval board.  Multilinx/USB works fine,
P-III cable fails to raise Done at the end.  5.2.02i software.

The P-III cable is marked 5 volt only, so I just assumed the 3.3
volts at the JTAG connector wasn't enough.  But I see an Answer
Record 8096 saying it should work at 5, 3.3, and 2.5 volts.
My experience with programming cables is you just keep trying
different things until something works, and hope it still works
tomorrow.


failure info for P-III cable:
Boundary-scan chain validated successfully.
Validating chain...
Boundary-scan chain validated successfully.
'2':Programming  device...
done.
INFO:iMPACT:579 - '2': Completed downloading bit file to device.
INFO:iMPACT:580 - '2':Checking done pin ....done.
'2': Programming terminated, Done did not go high.
PROGRESS_END - End Operation.
Elapsed time =      4 sec.
=>




Article: 56315
(removed)


Article: 56316
Subject: Re: Need help with Xilinx ISE
From: email_address@message.end
Date: Tue, 03 Jun 2003 03:33:09 GMT
Links: << >>  << T >>  << A >>

You're talking about 'Foundation 3.3i', right?  Yes, I have a copy.
I'll try to find the service packs -somewhere-.

Oddest thing:  I moved the source to another (the client's) system,
and exactly the same source synthesized with a 10% greater Fmax.

And it ran the clean-up passes whether it needed to or not.

I installed the software on both systems, and the service pack (3)
came from the same CD-ROM.  Somewhere there's a difference between the
two installs, and it is making a big difference.  Looks like I have a
ton of tool-chain debugging to do.  :(

This is making 'Brand-A' look better and better every day.   ;)

Do you have any tips on making the location constraints work work
4.2i?  I tried it according to the manual's definition, and it barfed
all over them.  I tried to locate a macro into one half of the chip,
and it insisted that I was trying to put it into the I/O cells, and
gave up.

Thanks Again,
Gary.

On Mon, 02 Jun 2003 14:26:43 GMT, Ray Andraka <ray@andraka.com> wrote:

>Hmm,   Not sure you can get it anymore if you don't already have it.  Ask
>your FAE for a copy.  No, I don't believe 5.2 supports the Spartan I's.  The
>problem with 4.2's router is it makes every path a critical path, so although
>you can see which path(s) fail timing, fixing those may not fix the
>underlying problem.
>
>
>email_address@message.end wrote:
>
>> Ray,
>>
>> What is v3.3sp8, and how do I get it?
>>
>> I can't use ISE-5.2 with a 5V Spartan, can I?
>>
>> Thanks,
>> Gary.
>>
>> On Sun, 01 Jun 2003 21:59:04 GMT, Ray Andraka <ray@andraka.com> wrote:
>>
>> >Use v3.3 sp8 instead.  The router in 4.x is lazy.  FWIW, I've had some
>> >good results so far with 5.2 sp3.  Seems Xilinx has fixed many of the
>> >problems I saw with the 4.2 router (Thank you).
>> >
>> >email_address@message.end wrote:
>> >
>> >> Hi all,
>> >>
>> >> Xilinx ISE is giving me fits.  I could swear that it hates me!  This
>> >> is version 4.2i, by the way.  Version 5 does not support the part I'm
>> >> using.
>> >>
>> >> Here's what's happening:
>> >>
>> >> The design is very close to -not- meeting the speed requirement, which
>> >> is 50 MHz.
>> >>
>> >> If, when ISE runs, it does 'improving timing' passes, the speed comes
>> >> out at 50.314 MHz.  If it does not run these passes, I get 47.246
>> >>
>> >> The problem is, I can't figure out how to get it to run these passes!
>> >> Some times it does, some times it doesn't.  The help file tells me to
>> >> check an option box, but that box doesn't exist!
>> >>
>> >> Please, how do I turn this option on?  Right now, ISE is stuck in the
>> >> mode where it does not run these cleanup passes.  :(
>> >>
>> >> And, if someone has a tutorial-like document for guiding place and
>> >> route, I would like to see it.  Basically, I want to 'suggest' to P&R
>> >> that certain (Verilog) modules belong in certain haves of the chip.
>> >>
>> >> Much Appreciated,
>> >> Gary
>> >> gwhelbig-at-yahoo-dot-com


Article: 56317
(removed)


Article: 56318
Subject: Re: Need help with Xilinx ISE
From: email_address@message.end
Date: Tue, 03 Jun 2003 03:34:29 GMT
Links: << >>  << T >>  << A >>
On 2 Jun 2003 09:00:05 -0700, billh40@aol.com (Bill Hanna) wrote:

>email_address@message.end wrote in message news:<sjmkdvo9n34acge8qne98kh6dsbundm8up@4ax.com>...
>> Hi all,
>> 
>> And, if someone has a tutorial-like document for guiding place and
>> route, I would like to see it.  Basically, I want to 'suggest' to P&R
>> that certain (Verilog) modules belong in certain haves of the chip.
>> 
>> Much Appreciated,
>> Gary
>> gwhelbig-at-yahoo-dot-com
>
>   Create a User Constaint File and set the 50MHz clock period constraint to 20 ns.
>   Add the UCF to the Implement properties. 
>
>Bill Hanna


Hi Bill,

Frequency constraints I can do.  It's -location- constraints that
aren't working.

Gary.

Article: 56319
Subject: Re: FPGA design: firmware or hardware?
From: "Neeraj Varma" <neeraj@cg-coreel.com>
Date: Tue, 3 Jun 2003 09:45:23 +0530
Links: << >>  << T >>  << A >>
"Soft Hardware"?



"H. Peter Anvin" <hpa@zytor.com> wrote in message
news:bbfvra$ug$1@cesium.transmeta.com...
> Followup to:  <3EDAE3D1.D3C52713@yahoo.com>
> By author:    rickman <spamgoeshere4@yahoo.com>
> In newsgroup: comp.arch.fpga
> >
> > So in summary, you consider firmware/software to be *any* alteration of
> > any form that can be performed on hardware as long as it is not
> > permanent, right?
> >
> > Where do you draw the line between software/firmware and simple
> > programming of registers?  Many application specific, standard product
> > (ASSP) chips do pretty much nothing until they are setup by configuring
> > the various registers in the chips.  This is not a lot different from
> > the typical sort of software/firmware that is programmed into a CPLD or
> > even a flash MCU.  I have seen ASSP chips that have a manual on usage
> > that is easily as large as an MCU.
> >
> > How do you distinguish ASSP chips from FPGAs in regards to the
> > programming?  Is the configuration of ASSP chips also called
> > software/firmware?
> >
>
> Yes, and that is not just me, either.  In fact, a lot of these kinds
> of chips require the driver to upload firmware, which sometimes
> trigger copyright concerns.  This is a common discussion topic on the
> Linux Kernel mailing list, and it's *always* referred to as firmware.
>
> -hpa
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64



Article: 56320
Subject: Re: HDLmaker update available
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 03 Jun 2003 00:20:48 -0400
Links: << >>  << T >>  << A >>
On Mon, 02 Jun 2003 17:24:11 -0400, Jacques athow wrote:

> "B. Joshua Rosen" <bjrosen@polybus.com> wrote in message
> news:<pan.2003.06.02.18.57.46.805141.2430@polybus.com>...
>> ModelSim support has returned to HDLmaker as of version 6.6.1. HDLmaker
>> is an open source Verilog/VHDL hierarchical code generator for FPGAs
>> and ASICs.
>> 
>> HDLmaker is available free of charge from Polybus Systems at
>> 
>> http://www.polybus.com/hdlmaker/users_guide/
> 
> I just checked this website and found out that it supports the Xilinx
> XC4000e series. Does this implies that I will be able to synthesize my
> old design and use the Free Xilinx implementation tool complete the
> process?
> 
> Jacques
 
HDLmaker isn't a synthesis tool, it writes hierarchical Verilog or VHDL,
generates pad rings, synthesis scripts and place and route constraint files.
It can still generate pad rings and constraint files for 4000 series
devices but you would still need a synthesis tool that understood the
devices and an old version of the Xilinx tools. The latest version of
HDLmaker no longer puts out the .cst files that were used by the old XACT
tools but the early versions of the current tool family (1.x or 2.x) had
support and for 4000 series devices and the .ucf constraint file format
(which HDlmaker does generate) so the constraint file put out by the
current version are compatible with those early rev Xilinx tools.

Article: 56321
Subject: Re: Parallel_case Synthesis directive
From: muthu_nano@yahoo.co.in (Muthu)
Date: 2 Jun 2003 21:22:58 -0700
Links: << >>  << T >>  << A >>
Mark Schellhorn <mark@seawaynetworks.com> wrote in message news:<Y6KCa.1870$V77.177463@news20.bellglobal.com>...
> parallel_case is used to tell the synthesis tool that it needn't worry about 
> priority of one case item over another because they are exclusive by design. 
> Consider this potential RTL code for a one-hot state machine:
> 
> case (1'b1) // parallel_case
>   R_state[0] : do_something;
>   R_state[1] : do_something_else;
>   R_state[2] : do_another_thing;
> endcase
> 
> I know that by design, only one bit of my R_state vector will ever be hot. The 
> synthesis tool, however, doesn't know this and will build a priority decoder 
> unless I tell it that the cases are exclusive (parallel).
> 
> If the case statement itself is exclusive, i.e.
> 
> case (R_state[1:0])
>   2'b00 : do_something;
>   2'b01 : do_something_else;
>   default : do_another_thing;
> endcase
> 
> then no parallel_case directive is needed. There is another directive called 
> infer_mux that can be used if the target technology library contains multiplexor 
> cells that the synthesis tool will not infer by default. It can be used to force 
> the tool to use these mux cells rather than building a mux out of gates, which 
> may or may not be desireable depending on your synthesis objectives.
> 
>     Mark

Hi Mark,

Nice explaination. 

My question is , Case doesn't imply MUX by default? Should we have
synthesis directive //Parallel_case

Regards,
Muthu

Article: 56322
Subject: Re: FPGA's an Flash
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 03 Jun 2003 01:25:37 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> Actually, the bonuses were good, the profit sharing adequate, and the fact
> that we had 0 layoffs, quite pleasant.
> 
> Who else can say that they were:  profitable, kept all of those inventive
> people happy, made lots of useful products for lots of customers (and sold
> them profitably),  had no layoffs, and improved customer services, and
> introduced new products besides?
> 
> No one.
> 
> Sorry.  Cheap shot on your part.  But Peter is correct:  the market decides,
> and it has voted overwhelming for our solutions.

Sorry if you feel it was a cheap shot.  But I felt that Peter's comment
was a cheap shot.  As to the specifics of Xilinx economics, I can't seem
to get to any data at Yahoo at the moment so I can't speak from facts,
but I follow Xilinx stock and I remember seeing some pretty red ink
flowing over the last two years.  Why else would the price drop from $90
per share to under $15?  

As to the market, the fat lady has not sung.  I like Xilinx products.  I
think they are pretty good, although not perfect.  But there are new
chips from the competion all the time and the competition is more than
just Altera.  I am finding the new Lattice parts to be very, very
interesting.  That does not take anything away from the advantages of
the Xilinx parts.  But it does present some new options offered by no
one else that I can find.  

Sometimes I think the image projected here for Xilinx is a bit smug.  I
am sorry if that offends you.  I understand that your paycheck comes
from Xilinx and you are one of their biggest cheerleaders.  But once in
awhile you and less often Peter cross a line when talking about the
competition.  Boosting your products is one thing, but trying to tell us
what is wrong with the competition is not anyone's forte.  Often I find
that the "facts" given in such a discussion are just plain wrong.  

A good example of of uneven comparison is the way that you often compare
the difficulty of making custom chips at current process technology vs.
buying FPGAs.  This is apples to oranges since a given design that can
be done on an FPGA can be done on a chip much smaller on a process two
years old.  The NRE of such a design will be much less than using
"current" technology and will still give a lower cost than FPGAs.  I
have yet to see you reply to a posting which brings up these facts. 
This is not germane to the issue discussed above, but illustrates my
point about uneven discussions.  

I don't wish to have an argument with you.  I am just giving my
opinion.  I hope you understand that.  

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56323
Subject: Re: FPGA's an Flash
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 03 Jun 2003 01:50:01 -0400
Links: << >>  << T >>  << A >>
Yes, Peter, the whole industry was down and Xilinx is no exception.  So
why did you claim that "all these companies so small and/or doing so
poorly"?  I didn't think you were gloating, but I also don't think it
was a reasonable assessment of the technology.  I felt your comment was
a cheap shot.  

I seem to recall some of your past postings where you mention that you
don't like to discuss the competition because doing so makes it look
like you are taking cheap shots, or something similar.  That is exactly
how it looked to me.  

I gave a much longer reply to Austin because I feel he projects an image
here that is a bit stronger in knocking the competition.  As I said
there, I like Xilinx products and I forgot to mention that I also like
their support.  I expect to be using the Spartan 3 in a new design
shortly.  But no technology is "perfect".  

The rational that you gave about company size is not valid.  There are
new chips out that have not seen their chance at the market place.  But
I can tell you that Xilinx is losing some sockets to them.  My design
has replaced two Coolrunner parts with the Lattice parts.  I thought the
Coolrunners were perfect for the job.  But Xilinx would not come down on
price on one and they put the part in too large a package for the
other.  I am sure I am not the only engineer who sees the advantages of
some of the new flash parts, even compared to the FPGAs.  BTW, Xilinx
FPGAs were never considered for these sockets because none of the
current families have 5 volt tolerance.  Seems that is making a comeback
these days.  

So I hope you can take my comments in the sense they were intended, not
as an insult or argument, but as a comment on what I am reading here.  


Peter Alfke wrote:
> 
> Rick, that's a cheap shot. The whole industry is down...
> But at least we did not lay off anybody, unlike some of our competitors.
> 
> I was not gloating, just pointing out that there must be a fly in the
> ointment with all those glorious technologies that were mentioned.
> 
> Peter Alfke
> =====================
> rickman wrote:
> >
> >
> > I remember a time when Xilinx stock was over 90.  Last time I checked it
> > was still below 30.  I bet there are some very unhappy investors out
> > there still.
> >
> > How was *your* bonus last year?  ;)
> >
> > --
> >
> > Rick "rickman" 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      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56324
Subject: Re: Parallel_case Synthesis directive
From: Muzaffer Kal <kal@dspia.com>
Date: Tue, 03 Jun 2003 06:53:29 GMT
Links: << >>  << T >>  << A >>
On 2 Jun 2003 21:22:58 -0700, muthu_nano@yahoo.co.in (Muthu) wrote:
>
>My question is , Case doesn't imply MUX by default? Should we have
>synthesis directive //Parallel_case

Verilog is specified similarly to C in that the entries in the case
statement are compared to the case expression one by one and if there
is a matching entry it is used. In this sense, case defines a priority
selector. If you want to enforce parallel case (which may or may not
generate smaller and/or faster hardware) you need to ask specifically.
In my opinion the best practice is to use if/else if construct for
priority and case for parallel select so that you can add
parallel_case by default to all case statements.

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations



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

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

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

Custom Search