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
2017JanFebMarApr2017

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 35675

Article: 35675
Subject: Re: future Xilinx products wish list ...
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 13 Oct 2001 02:34:26 GMT
Links: << >>  << T >>  << A >>


Tom Burgess wrote:<snip>
To solve the slow global reset problem, how about circuitry on each clock buffer that

> could disable it during reset, then synchronously re-enable it N clocks after
> end of reset, where N is programmable (0 for no delay), up to some reasonable maximum
> sufficient to accomodate the reset recovery time and max clock rate. Or some simpler
> scheme that would accomplish the same thing.

You have that capabilty, kind of, today in Virtex-II, where each clock buffer has an
enable input. What's missing is a timing circuit that blocks the clock appropriately.
Read the description of the BUFGCE in the newest version of the data sheet that goes on
the web this coming week ( and also to the printer soon thereafter)

Peter Alfke, Xilinx Applications

>
>
>


Article: 35676
Subject: Re: I need free PCI-Core (vhdl)!!
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 12 Oct 2001 19:55:19 -0700
Links: << >>  << T >>  << A >>
The Spartan-II PCI board worked in two computers both in room
temperature (about 20 degrees Celsius).
I have never worked with FPGAs up to that point, so I was pretty
anxious to program the external PROM, and see if the board will work.
The board somehow worked, so since then I haven't programmed the
external PROM because I haven't finished verifying the IP core
completely, and haven't been able to meet 33MHz PCI's timings.




Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)





Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E864.9F3363A9@andraka.com>...
> The timig analysis is worst case timing, which happens with high temperature and low supply voltage.  In my experience,
> Xilinx FPGAs will genarally work up to about 40% above the max frequency listed in the timing report in a lab environment
> (watch that temperature though).  I wouldn't go pushing these for something that is going to go out of the lab though.

Article: 35677
Subject: Re: High level synthesis will never work well :)
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 12 Oct 2001 20:04:55 -0700
Links: << >>  << T >>  << A >>
FYI, using VS.NET beta 2 VC++, good old "hello world" is 3.5 KB compiled -MD
(use C runtime DLL); and 36 KB with the whole, sprawling, statically linked
C runtime stdio.

Jan Gray, Gray Research LLC
(ex VC++ dev)




Article: 35678
Subject: Re: I need free PCI-Core (vhdl)!!
From: m8931612@student.nsysu.edu.tw (Ru-Chin Tsai)
Date: 12 Oct 2001 23:24:31 -0700
Links: << >>  << T >>  << A >>
"Ras Sim" <simsek@rhrk.uni-kl.de> wrote in message news:<49a92f681fea693317ee5a82213a3519.32396@mygate.mailgate.org>...
> Hi folks!
> I'm a student and i need a free PCI-Core wich is written in vhdl.
> Where could I download it ?
> 
> Greets
> Rasit

You can download try version PCI-Core from Altera SOFT-IP page.
The PCI compiler contain four kind PCI-Core function,you can download
it and simulate with your core design.
When you finish simulation and decide to program Altera device,you
should purchase it.

Altera soft-ip product site:
http://www.altera.com/products/ip/ipm-index.html

I suggest that you must have some knowledge about PCI bus.
Please reference some PCI bus book. I am sure that the PCI bus
timing protocol is complex. So you at least must have enough knowledge
befor combining your core design with PCI-Core

Article: 35679
Subject: Re: future Xilinx products wish list ...
From: hamish@cloud.net.au
Date: Sat, 13 Oct 2001 06:47:50 GMT
Links: << >>  << T >>  << A >>
Tim <tim@rockylogic.com.nospam.com> wrote:
> Maybe the long term plan is to configure/readback the big stuff
> via JTAG only - the details of ROM handling can be farmed out to a
> PAL.

Won't that be painfully slow for large devices?

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 35680
Subject: Re: future Xilinx products wish list ...
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 13 Oct 2001 08:49:16 +0100
Links: << >>  << T >>  << A >>


Theron Hicks wrote:

> I would think that a built-in crystal oscillator port would be a great
> option.  Also, I personally would like to see real LVPECL (i.e.suitable
> for single ended LVPECL inputs) with real LVPECL levels.  Also packages
> with pins (SMT pins are OK but not those ball grid arrays) for those who
> are using FPGA's as a short production run (read PROTOTYPE) device.
>
> Theron Hicks

While we're on the subject of what Austin Lesea calls the V-3 hopper:

Why not allow the drive strengths of the LVTTL/LVCMOS pins to be dynamically
configurable so I can set my DRAM outputs dependent on how many, how big
DIMMs are actually populated ?



Article: 35681
Subject: Re: High level synthesis will never work well :)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 13 Oct 2001 09:49:33 +0100
Links: << >>  << T >>  << A >>


Ken McElvain wrote:

> We are here...
>
> We do appreciate getting small examples that demonstrate potential
> improvements.  In general there is no need to go to the effort
> to produce the structural form.  All we need is a short description
> of what we missed - "You should have used the synch reset instead of
> building it in logic in front of the flip-flop".
>
> We have a large queue of improvements sorted by a function of how
> common they are, how much gain we are likely to get and how hard they
> are to implement.  This doesn't mean that you shouldn't bother to tell
> us about your desired improvement.  Even if we already have it in our
> queue, you are bumping our notion of how common the problem is.
>
> The best way to send us such a test case is via email at
>
> support@synplicity.com
>
> Please put both "QOR" and the target FPGA in the subject to
> help us route it.  The FPGA synthesis development team is pretty large.
>
> Thanks,
> Ken McElvain, CTO
>
> Andrew Brown wrote:
>
>

Ken,

The problem here is that there is no feedback.

In other words what would help is a publicly accessible database of
problems/inefficiencies and their workarounds/solutions like the Xilinx answers
DB. It sometimes seems that when I (maybe others as well) send in a bug report
it seems to vanish into a vacuum. I get an acknowlegement that there's a
problem and that's it. It gets worse when, as in a recent test case of mine, I
send in what appears to be a Xilinx MAP problem only to get told by Xilinx that
its really a synthesis problem and its been passed over to Synplicity.

This needs to be combined with a lisiting in the release notes for each version
of all issues (bugs + imporovements) that have been fixed. ModelSIM is the
paragon here.

I do appreciate that HDL synthesis  is complex and there's always the
possibility that fixing one thing will break something else or that my ``bug''
may be unique to me; stemming perhaps from pushing the boundaries of
synthesisability. That information is, in itself, very valuable.

IMO Synplify is the best of the bunch - at least for Xilinx parts - but with
some attention to the issues above you could win the engineer's ultimate
accolade `Synplify ? Great tool, low hassle'.

As a test case that's relevant to this thread since the problem relates to the
reset type - async/sync:

What's the status of bug report #33437 (register replication) ?




Article: 35682
Subject: Re: Reassemble a BGA560 device
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 13 Oct 2001 10:03:55 +0100
Links: << >>  << T >>  << A >>


Mike Treseler wrote:

> Juergen Otterbach wrote:
> >
> > Hallo usergroup,
> > in our lab we are working with a PCB assembled with a Virtex 1000 E BGA
> > device.
> > For a bigger FPGA design we want to replace this by a Virtex 2000E BGA
> > (means to take of the 1000E and resolder the 2000E).
>
> Removing and replacing a BGA device is not
> a problem for any manufacturing facility
> with a BGA rework station.
>
> Of course, you have to throw the old part away.
>
> Without the proper equipment and skills
> however, you may well destroy the board.
>
>       --Mike Treseler

We had a case some years ago where our assemblers had fitted a bunch of
XCV300-432BGAs 90 degrees rotated !! They had a re-work station and did
manage to get the parts off *but* they lost some of the pads doing it. These
were all on n/c balls and so we were o.k.. I believe the reason was that
n/c's have much less heat dissipation (no trace or pwr plane connection).

The real issue is that a BGA re-work station uses a metal box which is placed
over the BGA to form a mini-oven but, unlike the main re-flow oven, the whole
board doesn't go through the preheat, temperature profiling process.

Things may have got better since then ...





Article: 35683
Subject: Re: Maxplus waveform simulations
From: phil <philipp@synplicity.com>
Date: Sat, 13 Oct 2001 05:41:59 -0700
Links: << >>  << T >>  << A >>
hi, you can specify a faster clock speed by changing the grid size of the waveform editor. Thatīs very easy. 

Phil

Article: 35684
Subject: Re: I need free PCI-Core (vhdl)!!
From: Kolja Sulimma <kolja@sulimma.de>
Date: Sat, 13 Oct 2001 14:46:31 +0200
Links: << >>  << T >>  << A >>
The timings you get from the timing analyzer are based on worst case supply voltage,
temperature and the maximum load capacitance allowed on a PCI bus.
Additionally the setup and clock-to-out specifications of the PCI standard are based on a PCI bus with maximum trace length,
maximum number of slots and all slots populated.

If you want to sell a PCI core you better have it meet the worst case timing specifiaction, but for your own experiments that
is not necessary.
The last compile of my own PCI core has a clock-to-pad of 13.5ns and a setup time of 9.3ns and runs stable at 33 MHz in a fully
populated
PCI-Bus.

If you want to be on the safe side you can change the PCI clock frequency of you mainboard to 25MHz which will give you an
extra 10ns margin that can be devided between setup and clock-to-out times.
Also leaving some PCI slots empty should give you a couple of extra nanosecods.
See chapter 4.3.5 of the PCI standard.

Do not be too paranoid. It is perfectly normal for PCI boards to not to comply with the standard.
(Thats probably one of the reasons why many PCs run unreliably.)
- For example there existed PCI boards that only decoded 16-Bit of the IO address space.
- Many boards do not signal parity errors.
- I have an old VGA boards from a Compaq 75 MHz Pentium system. The board will only run at 25 MHz.
- I have not seen a single 5V board that fulfilled the decoupling requirements of chapter 4.4.2.2
an so on, and so on....

Kolja Sulimma





Kevin Brace wrote:

> The Spartan-II PCI board worked in two computers both in room
> temperature (about 20 degrees Celsius).
> I have never worked with FPGAs up to that point, so I was pretty
> anxious to program the external PROM, and see if the board will work.
> The board somehow worked, so since then I haven't programmed the
> external PROM because I haven't finished verifying the IP core
> completely, and haven't been able to meet 33MHz PCI's timings.
>
> Regards,
>
> Kevin Brace (don't respond to me directly, respond within the
> newsgroup)
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3BC6E864.9F3363A9@andraka.com>...
> > The timig analysis is worst case timing, which happens with high temperature and low supply voltage.  In my experience,
> > Xilinx FPGAs will genarally work up to about 40% above the max frequency listed in the timing report in a lab environment
> > (watch that temperature though).  I wouldn't go pushing these for something that is going to go out of the lab though.


Article: 35685
Subject: Re: PWM Signal in VHDL ?
From: renaux <renaux.jacky@wanadoo.fr>
Date: 13 Oct 2001 16:34:51 GMT
Links: << >>  << T >>  << A >>

May I suggest a slight change ? 

 if cnt = 0 then 
    cnt <= pwm_width ;
 else
    if direction = '1' then 
       cnt <= cnt+1;
    else
       cnt <= cnt-1;
  ..... 

 pwm <= direction ;

pwm will be 1 for (2!!n- pwm_width) and 0 for pwm_width+1 

the only change is : this implementation should not be 
         decoder dependant as the condition is always zero 
regards



-- 
User of http://www.foorum.com/. The best tools for usenet searching.

Article: 35686
Subject: FPGA Asynchronous Design
From: Phil Short <pjs@nospam.switchingpost.com>
Date: Sat, 13 Oct 2001 17:11:27 GMT
Links: << >>  << T >>  << A >>
Could anyone point me to references (hopefully on-line) for
implementing asynchronous (self-timed) designs using (in
particular) Xilinx FPGAs?  I am aware of the literature on
asynchronous design in general, and am interested in whether
anyone has completed non-trivial designs in FPGAs, and in
moderately specific techniques for doing this.

TIA,

--

Phil

Article: 35687
Subject: Re: how do I avoid glitches in this design?
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 13 Oct 2001 19:04:49 GMT
Links: << >>  << T >>  << A >>
I wonder if the DDR output flipflops in Virtex-II might be a solution for you.

They are designed to run of both edges of your clock, take two
data streams, and interweave them, and do it without glitches. If you did this
the result signal would be an output, and would use a pin. You could
route the result bak in over the PCB, or just add an input buffer in the same
I/O cell to bring the result back in for your ongoing enjoyment.

Philip


On Fri, 12 Oct 2001 23:33:07 +0100, "Johan Ditmar"
<johan.ditmar@nospamceloxica.com> wrote:
>Hello there,
>
>The past few days I have been trying to come up with a way to describe a
>generic pulse generator in Verilog (or VHDL) using shift registers. What I
>would like it to do is to take an arbitrary pulsetrain as a parameter (for
>example "100110") and then generate this pulse train repeatedly from an
>incoming clock signal. However, each bit in the pulse train corresponds to
>half an incoming clockcycle! I came up with the following scheme to do this:
>
>I implement two rotating shift registers (A and B) of three bits wide, one
>that is sensitive to the positive clock edge and one on the negative. I
>initialise one with the even bits of the pulse train ("101") and one with
>the odd ("010") and I let them run on the incoming clock.
>
>Then I generate a signal from the incoming clock, which simply follows this
>clock (using two flip flops, one positive and one negative edge sensitive),
>and I use this signal to either choose the output of shift register A or
>shift register B and this is then the output of the whole circuit.
>
>However, the output of this circuit is going to be used as a clock which
>feeds other circuits, so it should be glitch free. This is not always the
>case in my present design (I think). Is there some way to make my design
>glitch free? As the output changes on both positive and negative clock edge,
>I canīt put a simple register on the output :-( And I prefer not to use
>PLLīs or DLLīs (which may be used to generate the double clock frequency to
>make everything sensitive to the positive clock edge only).
>
>Any help is greatly appreciated!
>
>Regards,
>
>Johan Ditmar
>
>

Philip Freidin
Fliptronics

Article: 35688
Subject: Re: Lattice discontinues all smaller MACH circuits and other devices
From: Gerald Coe <gerry@devantech.demon.co.uk>
Date: Sat, 13 Oct 2001 20:34:14 +0100
Links: << >>  << T >>  << A >>

Thanks Jim, appreciated.

Regards,
Gerry.

In article <3BC7A69C.37B@designtools.co.nz>, Jim Granville <jim.granvill
e@designtools.co.nz> writes
>Gerald Coe wrote:
>> 
>> Hello
>> 
>> This is a concern to me,
>> Can you provide an on-line reference to this document?
>
>Lattice have just modified the links, and added these two
>
>http://www.latticesemi.com/lit/docs/pcns/010a_01.pdf
>
>http://www.latticesemi.com/lit/docs/appnotes/cpld/tn1007.pdf
>
>This details the affected devices, including those that will require 
>PCB redesigns.
>
>-jg
>
>> In article <99e2931.0110120320.49cf9aba@posting.google.com>, M. Praekelt
>> <martp@hotmail.com> writes
>> >Hello,
>> >as I read in comp.arch.embedded most i186 and i486 derivates build by
>> >AMD are discontinued.
>> >Now we got an announcement that this is the case also for a great
>> >bunch of MACH circuits produced for LATTICE in AMDs FAB 14 (which is
>> >intended to be closed).
>> >The list of devices in the PDF document spans 8 pages and contains
>> >PALCE  PALLV devices, MACH1xx, MACH 2xx, MACH4xx M4-xx and M5-xxx
>> >devices!
>> >
>> >Last order is 31 dec 2001 and last delivery 31 dec 2002!!!!
>> >
>> >I have posted this using another mail server a day ago, but I havent
>> >seen it up to now.
>> >I apologize if this message is reaching you twice.
>> >
>> >Perhaps we are the only ones around using this old-fashioned
>> >programmable devices....
>> >
>> >
>> >BTW: On http://www.latticesemi.com/products/mature/index.cfm
>> >you cannot read  **anything** about this up to now (12 oct 2001, 11:20
>> >UT)
>> 
>> --
>> Regards, Gerry
>> www.robot-electronics.co.uk

-- 
Regards, Gerry
www.robot-electronics.co.uk

Article: 35689
Subject: Re: FPGA Asynchronous Design
From: Ray Andraka <ray@andraka.com>
Date: Sat, 13 Oct 2001 20:59:56 GMT
Links: << >>  << T >>  << A >>
There was a group in the UK that had done some of this in FPGAs.  Be
aware, however, that this will involve a serious amount of handcrafting
for a robust design.  Cover terms necessary to avoid logic hazards are
optimzed out by the automatic tools, so you need to instantiate the
logic as LUTs or extensively use keep buffers in your design to keep the
logic constructed to avoid hazards.  The FPGA clocking is specifically
designed for synchronous design.  A self-timed design, in most cases is
going to make half the flip-flops unusable because the twoflip-flops use
the same clock.  FInally, the timing analysis is greatly complicated,
and is not supported by the current static timing tools.

For these reasons, the self timed stuff to date has been for much
smaller designs than those commonly done with synchronous logic.

Phil Short wrote:

> Could anyone point me to references (hopefully on-line) for
> implementing asynchronous (self-timed) designs using (in
> particular) Xilinx FPGAs?  I am aware of the literature on
> asynchronous design in general, and am interested in whether
> anyone has completed non-trivial designs in FPGAs, and in
> moderately specific techniques for doing this.
>
> TIA,
>
> --
>
> Phil

--
--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: 35690
Subject: Instantiating Virtex II library macros.
From: cantsay@here.com (Marko)
Date: Sat, 13 Oct 2001 22:04:32 GMT
Links: << >>  << T >>  << A >>
I'm trying to get familiar with Xilinx ISE 4.1i this weekend and have
the following problem...

I instantiate a design element macro in my Verilog code such as ..

OFD u1 (.I(q),.O(q),.C(clk));

but when I Synthesize, I get warnings beginning with...

Warning:  Cannot link cell 'test/u1' to its reference design 'OFD'.
(FPGA-LINK-2) and
Warning: The cell '/iotest/u3' is not linked to any design.
(FPGA-CHECK-4)

If I ignore the warnings and "Implement Design,"  I get an error...

ERROR:NgdBuild:604 - logical block 'u1' with type 'OFD' is unexpanded.
Symbol 'OFD' is not supported in target 'virtex2'.

This doesn't happen with "primitives," only with "macros."

What am I doing wrong?


mchampion@Xbigfoot.com (remove the X to send me email)

Article: 35691
Subject: How to instantiate I/O port with both registered input and output?
From: cantsay@here.com (Marko)
Date: Sat, 13 Oct 2001 22:18:28 GMT
Links: << >>  << T >>  << A >>
I am targeting Xilinx Virtex II with Verilog in an ISE4.1i
environment.  I want to instantiate (or infer) a single IOB which has
I/O capability, registered output, tristate output control, and
registered input.  Both registers can use the same clock.

I expected to find a design element in Xilinx's Library Guide, but
there is none.  

All of my attempts so far result in one or both registers being moved
out of the IOB into a CLB.  This won't work with my speed
requirements.

TIA
mchampion@Xbigfoot.com (remove the X to send me email)

Article: 35692
Subject: Re: How to instantiate I/O port with both registered input and output?
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sat, 13 Oct 2001 23:22:55 +0100
Links: << >>  << T >>  << A >>
Pack flops into IOBs via switches to the mapper.  From memory
it is something like '-pr b'.  Run map with no arguments to get
the switch list.

Virtex designs use regular flops in the IOBs, unlike 4K, etc., which
had magic IFD/OFD flops.


"Marko" <cantsay@here.com> wrote in message
news:3bc9bc39.59939438@dfiatx1-snr1.gtei.net...
> I am targeting Xilinx Virtex II with Verilog in an ISE4.1i
> environment.  I want to instantiate (or infer) a single IOB which has
> I/O capability, registered output, tristate output control, and
> registered input.  Both registers can use the same clock.
>
> I expected to find a design element in Xilinx's Library Guide, but
> there is none.
>
> All of my attempts so far result in one or both registers being moved
> out of the IOB into a CLB.  This won't work with my speed
> requirements.
>
> TIA
> mchampion@Xbigfoot.com (remove the X to send me email)



Article: 35693
Subject: Re: future Xilinx products wish list ...
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sat, 13 Oct 2001 23:38:41 +0100
Links: << >>  << T >>  << A >>
<hamish@cloud.net.au> wrote
> Tim <tim@rockylogic.com.nospam.com> wrote:
> > Maybe the long term plan is to configure/readback the big stuff
> > via JTAG only - the details of ROM handling can be farmed out to a
> > PAL.
>
> Won't that be painfully slow for large devices?

I guess.  For the XC2V10000 the times work out as
  JTAG         1000ms  (33MHz, 1-bit)
  Slave Serial  500ms  (66MHz, 1-bit)
  SelectMap      60ms  (66MHz, 8-bit)

Since this is a high-speed serial world, and JTAG is usually
limited to <50MHz (33MHz on Virtex) the future is presumably
a smart JTAG extension.






Article: 35694
Subject: Re: Synplicity/Leonardo License Agreement Information
From: brimdavis@aol.com (Brian Davis)
Date: 13 Oct 2001 18:48:51 -0700
Links: << >>  << T >>  << A >>
Andy Peters <andy@exponentmedia.deletethis.com> wrote:
> 
> Uh oh!  The person who posted Synplify's results for that 56-bit counter
> problem is in line for an ass-whooping!
> 
> -a

Andy,

 They haven't remotely detonated my key ( or my ass ) yet :)

 According to the Synplify license ( excerpt copyright Synplicity ):

  "Licensee acknowledges that the scope of the licenses granted
   hereunder do not permit Licensee (and Licensee shall not allow
   any third party) to:"
<snip>
   "(iv) disclose the results of any benchmarking of the SOFTWARE,
   or use such results for its own competing software development
   activities, without the prior written permission of Synplicity;"

 Personally, I wouldn't consider answering a question on how to make
a counter synthesize better to be a "benchmark"... 

  But then again, nor would I make the software guys writing the 
synthesis tool insert a copyright message into any cuts and pastes
done from the online help code examples...

Brian

p.s. : upon further reflection, perhaps I should have checked to see if
 posting an excerpt of the license terms is a violation of the license...

Article: 35695
Subject: Re: FPGA Asynchronous Design
From: Phil Short <pjs@nospam.switchingpost.com>
Date: Sun, 14 Oct 2001 02:14:40 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> For these reasons, the self timed stuff to date has been for much
> smaller designs than those commonly done with synchronous logic.
> 
Seems like a lot of work if you have to battle with your tools the
whole way.  I guess you have to really be determined to implement
a self-timed design in a Xilinx FPGA.

--

Phil

Article: 35696
Subject: Re: Synplicity/Leonardo License Agreement Information
From: brimdavis@aol.com (Brian Davis)
Date: 13 Oct 2001 21:07:40 -0700
Links: << >>  << T >>  << A >>
>From the Webpack XST license ( excerpt copyright Xilinx ):

   "2. Restrictions."
 <snip> 
    "You may not publish any data or information that compares 
    the performance of the Software with software created or 
    distributed by others."


 ( Had I posted both license excerpts in the same message, would
that constitute 'license benchmarking' ? )

----------------------------------------------------------------

> Uh oh!  The person who posted Synplify's results for that 56-bit
> counter problem is in line for an ass-whooping!

  Upon even more reflection, should it come to that, I could
probably plead insanity vis-a-vis my original counter post:

  JUDGE: How do you explain this egregious posting of useful
   information?

  DEFENDANT: But your Honor, after reading 3000 responses about
   asynchronous resets and GSR, none of which clarified the cause
   of the coherently cleared counter curiously containing copious 
   CLBs, I just HAD to post a message explaining the paradoxical 
   result that lowering the synthesis target frequency would result
   in a counter that is both smaller and faster after P&R.

  JUDGE: For your offense, and in the light of your excessive
   alliteration of words beginning with the letter "C", I hereby 
   sentence you to use FPGA Express for all future synthesis work. 
   Bailiff, take him away.


Brian

Article: 35697
Subject: Re: future Xilinx products wish list ...
From: Eric <erv_NOS_PAM@sympatico.ca>
Date: Sun, 14 Oct 2001 00:17:39 -0400
Links: << >>  << T >>  << A >>
Hi,

Tim wrote:

> Another point of view...
>
> I disagree on the dual-use of pins.

Could you explain why you disagree ?
What kind of problem would it create for your app ?

> Please put ALL the config, etc,
> pins on the VCCAUX supply.

Here too, it would be better if you could explain why.

> I.E. on non-banked balls.

Maybe I miss something here, but I really can't see why it could be a problem
that D0-D7 and other signals are part of a IO bank as they are now.
With the selectMap mode, you can keep them dedicated if you need to
(they call it the "persist" option) so you get the best of both worlds.

>  I guess we could
> also have an option to connect some of these to the logic matrix.  The
> V2 lineup is so much better than the 4K/Virtex arrangements, but it is
> still annoying to have config spread between VCCAUX and whatever
> voltages banks 4 and 5 are set at.

Maybe all the pins that are already dual use would do better if they were
grouped on a single or a separate bank. However, I don't see where the
problem is for you since you seem to to configuration through JTAG and
you don't use these pin's alternate function.

>
> Maybe the long term plan is to configure/readback the big stuff
> via JTAG only -

It's not because you don't use other configuration methods that they're
useless.

Also, as Hamish Moffatt wrote, JTAG speed is not too fast. SelectMap is
around 16x faster. Should xilinx forget about Jtag and promote SelectMap as
the only way to configure / readback an FPGA ? Certainly not ! Both are
possible, choice is yours.

> the details of ROM handling can be farmed out to a
> PAL.

Requiring an added, (soon to be obsolete) PAL chip where the FPGA could do it
at no extra cost and without any consequences for other users escapes me
(Am I missing a major drawback here ?).

Similarly, the details of proper signal termination can be farmed out to a bunch
of discrete resistors. However, Virtex II integrates the function on chip and users
who need it welcome this added function. Others simply don't use it.

The most important question here is whenever there is enough demand for that
parallel master mode with an added address generation counter feature.
I think there is, mostly for system that closely integrate processors and FPGAs,
and also for systems that need large / fast reprogrammable configuration memory
(an XCV2600E requires 4x XC18V04 while a single, standard flash rom such as this
one: http://www.ssti.com/products/39lf_vf080_016.html would do, up to a XCV3200E ).

One thing that's important is that if any of these enhancements are made, they should
be transparent for users who don't need them.

regards,

Eric.


Article: 35698
Subject: Re: future Xilinx products wish list ...
From: hamish@cloud.net.au
Date: Sun, 14 Oct 2001 07:22:09 GMT
Links: << >>  << T >>  << A >>
Tim <tim@rockylogic.com.nospam.com> wrote:
> <hamish@cloud.net.au> wrote
>> Won't that be painfully slow for large devices?

> I guess.  For the XC2V10000 the times work out as
>  JTAG         1000ms  (33MHz, 1-bit)
>  Slave Serial  500ms  (66MHz, 1-bit)
>  SelectMap      60ms  (66MHz, 8-bit)

Hmm, that's not so bad. We're byte-banging from the CPU (through a CPLD)
in SelectMap mode and it takes a couple of seconds already for an
XCV2000E.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 35699
Subject: Re: Instantiating Virtex II library macros.
From: hamish@cloud.net.au
Date: Sun, 14 Oct 2001 07:29:20 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga Marko <cantsay@here.com> wrote:
> I instantiate a design element macro in my Verilog code such as ..

[..]

> This doesn't happen with "primitives," only with "macros."
> What am I doing wrong?

In my experience, you can't instantiate Xilinx macros in your
HDL code. Ngdbuild doesn't know anything about them (only
primitives). 

You can use macros in schematics and in this case your schematic 
editor's netlist writer must expand the macros.

In this case you must instantiate an FD + OBUF. Or infer the
FD and instantiate the OBUF. Or better yet, infer both (if
your synthesis tool is half-intelligent).


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



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
2017JanFebMarApr2017

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