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 72825

Article: 72825
Subject: Re: Unisim Library
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Fri, 03 Sep 2004 12:51:30 GMT
Links: << >>  << T >>  << A >>
If you are using PE/LE/SE then:
1, Look up how to use the Xilinx compxlib utility
2, Compile your Unisim library using compxlib (you might want to do Simprim
and XilinxCorelib at the same time)
3 Invoke Modelsim and add a mapping for the unisim library (alternatively
just update your modelsim.ini file)
4 Try again...:-)

Hans.
www.ht-lab.com


"Mohamed Elnamaky" <mnamky@hotmail.com> wrote in message
news:bceb5f12.0409030238.4fa92ddf@posting.google.com...
> Dear All;
>
> please, I need to use the library of Unisim from Xilinx in my VHDL
> code simulated with ModelSim. How can I make the link? I appreciate
> your time answering a basic question like that but it is urgent.
>
> Thank you



Article: 72826
Subject: Re: Sentinel dongle no longer detected by Quartus
From: "Hans" <hansydelm@no-spam-ntlworld.com>
Date: Fri, 03 Sep 2004 12:57:05 GMT
Links: << >>  << T >>  << A >>
Hi Wilhelm,

If your dongle is Flexlm based you can check your dongle driver using the
following command from a DOS box/Cygwin shell

lmutil lmhostid -flexid

If your driver is working the above command should return your dongle ID
(7-xxxxxxxx/8-xxxxxxxx), if not the you need to re-install the driver,

Hans.
www.ht-lab.com


"Wilhelm Klink" <kommandantklink@hotmail.com> wrote in message
news:6011e208.0408312252.3b0ef36@posting.google.com...
> I'm running Quartus (versions 4.0 and 4.1) on a Dell Inspiron 8600,
> with a dongle connected to the parallel port.  The other day the
> dongle stopped being detected in Quartus.  A printer still works off
> the port so it is fine, and port is set to ecp as required.  The
> dongle works with other machines I am using.  Has anyone got a program
> to determine the problem between the dongle and the parallel port?
> Maybe I will have to resort to using a debug tool to locate the
> problem.



Article: 72827
Subject: CPLD : Is there a way
From: Lolotheguru <lolotheguru@hotmail.com>
Date: Fri, 3 Sep 2004 08:08:45 -0700
Links: << >>  << T >>  << A >>
Is there a way to get the schematics of the desing out of the .JED file !
Is it possible ?
Thanks and best regards

Article: 72828
Subject: [XC96xxXL] Maximum Value for the external Pull-Up resistor ...
From: meng.engineering@bluewin.ch (Markus Meng)
Date: 3 Sep 2004 09:05:33 -0700
Links: << >>  << T >>  << A >>
Hi all,

I just wonder if someone else did make the same measurements.

We do have a system with a 9572XL having inputs with an external
47KOhm resistor. The design has done by another person. I prefer pull-up
resistors in the 3.3K...10K max value ranges.

We did have strange behavior until I did measure the voltage on
these inputs pins. After configuration through JTAG we do have
a clean 3.3VDC pulled up input value ...

Bringing one of these inputs to GND and releasing it again, shows
with the oscilloscope, that the voltage on these pins doese rise until
0.9Volt but not higher. Thought the external pull-up resistor should
bring these inputs - only - in the design back to 3.3VDC again. No
way, once these pins have been brought to GND, the release of it give
us a voltage rise up to 0.9VDC but not more.

This explains a lot, why even the simplest logic did give us a real blues ...

However reducing to the external pull-up resistors to below 10K, we
found everything is working as expected.
Checking the datasheet a see a max input current for the
inputs of +-10 uA. Multiplying this value with 47K gives us 0.47V max ...

It seems that this max value is somehow not the max value ....
(On these inputs, there is no additional cap ...)

Any idea?

Markus

Article: 72829
Subject: Re: [XC96xxXL] Maximum Value for the external Pull-Up resistor ...
From: "Mike Lewis" <someone@micrsoft.com>
Date: Fri, 3 Sep 2004 12:18:08 -0400
Links: << >>  << T >>  << A >>
Current flowing through the resistor results in the voltage
drop from 3.3v to 0.9v. The larger the resistance the greater
the voltage drop. I wouldn't think this to be an FPGA specific
issue but more a system issue. It would depend on what
devices are connected to the signal and what their current
draws are.

Mike


"Markus Meng" <meng.engineering@bluewin.ch> wrote in message
news:aaaee51b.0409030805.40975c3f@posting.google.com...
> Hi all,
>
> I just wonder if someone else did make the same measurements.
>
> We do have a system with a 9572XL having inputs with an external
> 47KOhm resistor. The design has done by another person. I prefer pull-up
> resistors in the 3.3K...10K max value ranges.
>
> We did have strange behavior until I did measure the voltage on
> these inputs pins. After configuration through JTAG we do have
> a clean 3.3VDC pulled up input value ...
>
> Bringing one of these inputs to GND and releasing it again, shows
> with the oscilloscope, that the voltage on these pins doese rise until
> 0.9Volt but not higher. Thought the external pull-up resistor should
> bring these inputs - only - in the design back to 3.3VDC again. No
> way, once these pins have been brought to GND, the release of it give
> us a voltage rise up to 0.9VDC but not more.
>
> This explains a lot, why even the simplest logic did give us a real blues
...
>
> However reducing to the external pull-up resistors to below 10K, we
> found everything is working as expected.
> Checking the datasheet a see a max input current for the
> inputs of +-10 uA. Multiplying this value with 47K gives us 0.47V max ...
>
> It seems that this max value is somehow not the max value ....
> (On these inputs, there is no additional cap ...)
>
> Any idea?
>
> Markus



Article: 72830
Subject: Re: [XC96xxXL] Maximum Value for the external Pull-Up resistor ...
From: Peter Wallace <pcw@karpy.com>
Date: Fri, 03 Sep 2004 09:20:32 -0700
Links: << >>  << T >>  << A >>
On Fri, 03 Sep 2004 10:05:33 -0700, Markus Meng wrote:

> Hi all,
> 
> I just wonder if someone else did make the same measurements.
> 
> We do have a system with a 9572XL having inputs with an external 47KOhm
> resistor. The design has done by another person. I prefer pull-up
> resistors in the 3.3K...10K max value ranges.
> 
> We did have strange behavior until I did measure the voltage on these
> inputs pins. After configuration through JTAG we do have a clean 3.3VDC
> pulled up input value ...
> 
> Bringing one of these inputs to GND and releasing it again, shows with
> the oscilloscope, that the voltage on these pins doese rise until
> 0.9Volt but not higher. Thought the external pull-up resistor should
> bring these inputs - only - in the design back to 3.3VDC again. No way,
> once these pins have been brought to GND, the release of it give us a
> voltage rise up to 0.9VDC but not more.
> 
> This explains a lot, why even the simplest logic did give us a real
> blues ...
> 
> However reducing to the external pull-up resistors to below 10K, we
> found everything is working as expected. Checking the datasheet a see a
> max input current for the inputs of +-10 uA. Multiplying this value with
> 47K gives us 0.47V max ...
> 
> It seems that this max value is somehow not the max value .... (On these
> inputs, there is no additional cap ...)
> 
> Any idea?
> 
> Markus

XC9572XL have bus hold circuitry on inputs. Unless you overpower the bus
hold circuit with your pullup resistor, you will have funny I/O levels. 

Not sure but maybe you can program input for pullups instead of buss
hold...


Peter Wallace

Article: 72831
Subject: Re: Fanout Xilinx
From: Jim Wu <NOSPAM@nospam.com>
Date: Fri, 03 Sep 2004 13:44:39 -0400
Links: << >>  << T >>  << A >>
> 
> 2) What are Tiopi, Tilo and Tioop? Are they different type of wires?
> Where is documentation for these things? I can't seem to find them in
> the help files.

They are different timing parameters. If you have ISE installed, check 
doc\usenglish\help\timingan\html directory for descriptions about them. 
(e.g. for Tioipi, search for file ta_tiopi.htm)

HTH,
Jim (jimwu88NOOOSPAM@yahoo.com remove NOOOSPAM)
http://www.geocities.com/jimwu88/chips

Article: 72832
Subject: Re: Spartan 3 Starter Kit and ISE WebPACK
From: Kroko <Kroko@nil.com>
Date: Fri, 03 Sep 2004 20:10:14 +0200
Links: << >>  << T >>  << A >>

>Just to clarify what comes with the Spartan-3 Starter Kit, it includes two
>software license codes.  One code is for the Xilinx WebPack software (CD-ROM
>included), which never expires.  WebPack supports the XC3S200 FPGA found on
>the Starter Kit board as well as the smaller XC3S50 and the larger XC3S400
>FPGAs.

Thanks, I finally understand :-)

Kroko.


Article: 72833
Subject: Is Stratix-II ALM some kind of partitionable LUT
From: SG <gupt@hotmail.com.NOSPAM>
Date: 03 Sep 2004 12:13:10 -0700
Links: << >>  << T >>  << A >>

The subject says it all.  Is the ADaptive Logic Module (ALM) in the
Stratix-II some kind of partitionable 7-LUT ?  Altera claims they can
map two functions to the same LUT and get the same timing as if it
were one LUT for each.  That sounds like some kind of partitionable
7-LUT.  Is that how it is ?

Thanks
Sumit

Article: 72834
Subject: Re: Spartan 3 Starter Kit and ISE WebPACK
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 03 Sep 2004 16:08:52 -0400
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> 
> Kroko <Kroko@nil.com> writes:
> > Is it only possible for a limited time, or is there no time limit ?
> > What I mean is, I don't want to use an evaluation version of some
> > software that costs me a lot to buy later when the evaluation period
> > is over ! And I need more that a few month to complete the project i
> > have in mind ....
> 
> If they're the usual Xilinx evaluation CDs, they'll work as both
> a time-limited full-featured ISE evaluation, and as a non-time-limited
> Webpack.  You can use the time-limited evaluation to decide whether
> the features missing from Webpack are worth purchasing.
> 
> I've found that WebPack is sufficient for doing some fairly sophisticated
> things, though I sometimes wish it had the FPGA Editor.

Anyone know why the FPGA Editor is not included in the Web version? 
Seems that there shouldn't be any licensing issues.  Is it just a matter
of not giving you everything because they want to sell it?  

-- 

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: 72835
Subject: Re: [XC96xxXL] Maximum Value for the external Pull-Up resistor ...
From: Mark Ng <mark.ng@xilinx.com>
Date: Fri, 03 Sep 2004 14:20:07 -0700
Links: << >>  << T >>  << A >>
Hi Markus,

Peter is correct.  Your external 47k ohm resistors are too weak to over 
come the Bus Hold circuit in the 9500xl.

Your options are:

	a)  Use pullup resistors that are no greater than 10k

or
	b)  Float the IO's using the ISE GUI option.  (Implement -> 	
             Properties -> Fitting Tab -> Float)

I'd recommend option a), as floating IOs is not recommended unless you 
have properly terminated all IO's...A floating input voltage will cause 
the input buffer to potentially oscillate, and will cause the device to 
draw unnecessary power....

Thanks,
Mark

Peter Wallace wrote:
> On Fri, 03 Sep 2004 10:05:33 -0700, Markus Meng wrote:
> 
> 
>>Hi all,
>>
>>I just wonder if someone else did make the same measurements.
>>
>>We do have a system with a 9572XL having inputs with an external 47KOhm
>>resistor. The design has done by another person. I prefer pull-up
>>resistors in the 3.3K...10K max value ranges.
>>
>>We did have strange behavior until I did measure the voltage on these
>>inputs pins. After configuration through JTAG we do have a clean 3.3VDC
>>pulled up input value ...
>>
>>Bringing one of these inputs to GND and releasing it again, shows with
>>the oscilloscope, that the voltage on these pins doese rise until
>>0.9Volt but not higher. Thought the external pull-up resistor should
>>bring these inputs - only - in the design back to 3.3VDC again. No way,
>>once these pins have been brought to GND, the release of it give us a
>>voltage rise up to 0.9VDC but not more.
>>
>>This explains a lot, why even the simplest logic did give us a real
>>blues ...
>>
>>However reducing to the external pull-up resistors to below 10K, we
>>found everything is working as expected. Checking the datasheet a see a
>>max input current for the inputs of +-10 uA. Multiplying this value with
>>47K gives us 0.47V max ...
>>
>>It seems that this max value is somehow not the max value .... (On these
>>inputs, there is no additional cap ...)
>>
>>Any idea?
>>
>>Markus
> 
> 
> XC9572XL have bus hold circuitry on inputs. Unless you overpower the bus
> hold circuit with your pullup resistor, you will have funny I/O levels. 
> 
> Not sure but maybe you can program input for pullups instead of buss
> hold...
> 
> 
> Peter Wallace

Article: 72836
Subject: Re: Is Stratix-II ALM some kind of partitionable LUT
From: Ben Twijnstra <btwijnstra@chello.nl>
Date: Fri, 03 Sep 2004 21:51:28 GMT
Links: << >>  << T >>  << A >>
SG wrote:

> 
> The subject says it all.  Is the ADaptive Logic Module (ALM) in the
> Stratix-II some kind of partitionable 7-LUT ?  Altera claims they can
> map two functions to the same LUT and get the same timing as if it
> were one LUT for each.  That sounds like some kind of partitionable
> 7-LUT.  Is that how it is ?
> 
> Thanks
> Sumit

Try this page:

http://www.altera.com/products/devices/stratix2/features/architecture/st2-lut.html

It's a bit complex, but it's best to let Altera's software tackle the
intricacies.

Ben


Article: 72837
Subject: Xilinx Xpower Issues - Help from xilinx team please
From: mukesh.chugh@gmail.com (Mukesh Chugh)
Date: 3 Sep 2004 15:13:01 -0700
Links: << >>  << T >>  << A >>
Hi,

I am facing following issues when using Xpower to calculate the
dynamic power for my design:

Tools being used:
Xilinx ISE 6.2, Xpower 6.2.03i
ModelSim XE II/ Starter 5.7g

I am generating the .vcd file during post PAR simulation and then
using this file for xpower along with .ncd and .pcf files. I get a lot
of warnings like:

WARNING:Power:763 - Only 41% of the design signals toggle.

WARNING:Power:216 - VCDFile(564214): $dumpoff command encountered, all
simulation data after this will be ignored.
INFO:Power:555 - Estimate is reasonable based on analysis of the
design, user
WARNING:Power:91 - Can't change frequency of net clk to 166.67Mhz.
WARNING:Power:91 - Can't change frequency of net clk to 165.83Mhz.
WARNING:Power:91 - Can't change frequency of net clk_BUFGP/IBUFG to
165.83Mhz.
WARNING:Power:91 - Can't change frequency of net clk_BUFGP to
165.83Mhz.
WARNING:Power:91 - Can't change frequency of net GLOBAL_LOGIC0 to
0.83Mhz.
WARNING:Power:91 - Can't change frequency of net ce_IBUF to 0.83Mhz.
WARNING:Power:91 - Can't change frequency of net clk to 165.83Mhz.
WARNING:Power:91 - Can't change frequency of net clk_BUFGP/IBUFG to
165.83Mhz.
		parsing completed in: 0 secs 
WARNING:Power:91 - Can't change frequency of net ce_IBUF to 0.83Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in4_0_IBUF to
0.83Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in4_1_IBUF to
0.83Mhz.
......
WARNING:Power:91 - Can't change frequency of net gateway_in4_8_IBUF to
0.83Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in8_IBUF to
25.83Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in10_IBUF to
26.67Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in9_IBUF to
25.83Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in5_0_IBUF to
1.67Mhz.
WARNING:Power:91 - Can't change frequency of net gateway_in5_1_IBUF to
0.83Mhz.
......
.
WARNING:Power:91 - Can't change frequency of net gateway_in3_3_IBUF to
26.67Mhz.
WARNING:Power:763 - Only 42% of the design signals toggle.
WARNING:Power:763 - Only 42% of the design signals toggle.

the report summary is 
Power summary:                        I(mA)    P(mW)
----------------------------------------------------------------
Total estimated power consumption:               553
                               ---
                      Vccint 1.50V:      146      220
                      Vccaux 3.30V:      100      330
                      Vcco33 3.30V:        1        3
                               ---
                           Clocks:        0        0
                           Inputs:        3        5
                            Logic:       61       91
                          Outputs:
                             Vcco33       0        0
                          Signals:       17       26
                               ---
           Quiescent Vccint  1.50V:       65       98
           Quiescent Vccaux  3.30V:      100      330
           Quiescent Vcco33  3.30V:        1        3
             Startup Vccint  1.5V:      200
             Startup Vccaux  3.3V:      100
             Startup Vcco33  3.3V:       50
                               ---

My Questions:
- How come I get clock power zero? In another smaller testdesign of
counters, I do get some power although logic power in that case is
very less.
- The activity rate for clock nets is zero. How?
- I get the correct simulation but the power results seem incorrect.
- Whats the meaningof such warnings?

--
Mukesh

Article: 72838
Subject: Re: Completed my first Virtex4 design
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 03 Sep 2004 15:40:35 -0700
Links: << >>  << T >>  << A >>
Philip Freidin <philip@fliptronics.com> writes:
> Some of the manuals are single page PDFs, that point you to
> the web site to get the real thing.

Ugh!  I always hate that sort of thing.  CDs are cheap, they should
include the real docs.  (It's all well and good to suggest looking at
the web site for updates.)

What happens in five years when a customer needs you to revise an
old design?  You discover that Foundation ISE 11.2 doesn't support
the old parts, or that for some reason the old design doesn't build
right with it, so you get out your old CD of ISE 6.3.  And then
discover that you don't have the actual documentation.

Years ago people told me that as more and more information became
available digitally, particular works would be available on a permanent
basis, because storage capacity and bandwidth keep increasing, and
there's no longer an reason why things should go out of print.  The
publisher doesn't have to keep a warehouse of books that only sell a
copy occasionally; instead it is just bits on a hard drive.

While there may be some small amount of truth to that, the reality is
that most digital works are even more ephemeral than the paper they are
replacing.

Sigh.

Article: 72839
Subject: Re: Completed my first Virtex4 design
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 04 Sep 2004 02:17:32 GMT
Links: << >>  << T >>  << A >>
On Fri, 03 Sep 2004 17:52:50 +1200, Jim Granville <no.spam@designtools.co.nz> wrote:
>  Wot, No Speed reports ?
>You should try a 32 bit ctr, and see what it reports :)
>-jg

Sure, with an input register and output register to isolate the
counter performance from the I/O performance.

Set clock period goal to 250 MHz.

====
module top(in_bus,out_bus,clock);

    input [31:0]	in_bus;
    output [31:0]	out_bus;
    input			clock;

	reg	[31:0]	counter;
	reg	[31:0]	in_bus_reg;
	reg	[31:0]	out_bus_reg;


	always @(posedge clock) begin
		counter <= counter + 1;
	 	out_bus_reg <= counter | in_bus_reg;
	 	in_bus_reg  <= in_bus;
	end

assign out_bus = out_bus_reg;

endmodule
====

Trimmed PAR report:
Release 6.3i Par G.35
Copyright (c) 1995-2004 Xilinx, Inc.  All rights reserved.
Fri Sep 03 19:03:36 2004
E:/Xilinx/bin/nt/par.exe -w -intstyle ise -ol high -t 1 top_map.ncd top.ncd top.pcf 
Loading device database for application Par from file "top_map.ncd".
   "top" is an NCD, version 2.38, device xc4vfx12, package sf363, speed -11
Loading device for application Par from file '4vfx12.nph' in environment
E:/Xilinx.
Device speed data version:  PREVIEW 1.46 2004-07-09.
Device utilization summary:

   Number of External IOBs            65 out of 240    27%
      Number of LOCed External IOBs    0 out of 65      0%

   Number of ILOGICs                  32 out of 320    10%
   Number of OLOGICs                  32 out of 320    10%
   Number of Slices                   16 out of 5472    1%

   Number of BUFGs                     1 out of 32      3%

Overall effort level (-ol):   High (set by user)
Placer effort level (-pl):    High (set by user)
Placer cost table entry (-t): 1
Router effort level (-rl):    High (set by user)

Starting initial Timing Analysis.  REAL time: 11 secs 
Finished initial Timing Analysis.  REAL time: 11 secs 

+-------------------------+----------+------+------+------------+-------------+
|        Clock Net        | Resource |Locked|Fanout|Max Skew(ns)|Max Delay(ns)|
+-------------------------+----------+------+------+------------+-------------+
|       clock_BUFGP       |BUFGCTRL_X| No   |   80 |  0.433     |  1.655      |
+-------------------------+----------+------+------+------------+-------------+

--------------------------------------------------------------------------------
  Constraint                                | Requested  | Actual     | Logic 
                                            |            |            | Levels
--------------------------------------------------------------------------------
  TS_clock = PERIOD TIMEGRP "clock"  4 nS   | 4.000ns    | 3.673ns    | 0    
   HIGH 50.000000 %                         |            |            |      
--------------------------------------------------------------------------------
  OFFSET = IN 10 nS  BEFORE COMP "clock"    | 10.000ns   | 5.562ns    | 2    
--------------------------------------------------------------------------------
  OFFSET = OUT 10 nS  AFTER COMP "clock"    | 10.000ns   | 6.316ns    | 1    
--------------------------------------------------------------------------------

Total REAL time to PAR completion: 1 mins 9 secs 
Total CPU time to PAR completion: 1 mins 9 secs 
Peak Memory Usage:  142 MB



Timing report:

(selected pieces)

================================================================================
Timing constraint: TS_clock = PERIOD TIMEGRP "clock"  4 nS   HIGH 50.000000 % ;

 592 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold errors)
 Minimum period is   3.673ns.
--------------------------------------------------------------------------------
Slack:                  0.327ns (requirement - (data path - clock path skew + uncertainty))
  Source:               counter_10 (FF)
  Destination:          out_bus_reg_10 (FF)
  Requirement:          4.000ns
  Data Path Delay:      3.673ns (Levels of Logic = 0)
  Clock Path Skew:      0.000ns
  Source Clock:         clock_BUFGP rising at 0.000ns
  Destination Clock:    clock_BUFGP rising at 4.000ns
  Clock Uncertainty:    0.000ns

  Data Path: counter_10 to out_bus_reg_10
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X47Y75.XQ      Tcko                  0.290   counter<10>
                                                       counter_10
    OLOGIC_X0Y74.SR      net (fanout=2)        2.604   counter<10>
    OLOGIC_X0Y74.CLK     Tosrck                0.779   out_bus_reg<10>
                                                       out_bus_reg_10
    -------------------------------------------------  ---------------------------
    Total                                      3.673ns (1.069ns logic, 2.604ns route)
                                                       (29.1% logic, 70.9% route)




--------------------------------------------------------------------------------
Slack:                  1.254ns (requirement - (data path - clock path skew + uncertainty))
  Source:               counter_1 (FF)
  Destination:          counter_31 (FF)
  Requirement:          4.000ns
  Data Path Delay:      2.741ns (Levels of Logic = 16)
  Clock Path Skew:      -0.005ns
  Source Clock:         clock_BUFGP rising at 0.000ns
  Destination Clock:    clock_BUFGP rising at 4.000ns
  Clock Uncertainty:    0.000ns

  Data Path: counter_1 to counter_31
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X47Y70.YQ      Tcko                  0.290   counter<0>
                                                       counter_1
    SLICE_X47Y70.G3      net (fanout=2)        0.364   counter<1>
    SLICE_X47Y70.COUT    Topcyg                0.476   counter<0>
                                                       counter<1>_rt
                                                       counter_LPM_COUNTER_1__n0000<1>cy
    SLICE_X47Y71.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<1>_cyo
    SLICE_X47Y71.COUT    Tbyp                  0.083   counter<2>
                                                       counter_LPM_COUNTER_1__n0000<2>cy
                                                       counter_LPM_COUNTER_1__n0000<3>cy
    SLICE_X47Y72.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<3>_cyo
    SLICE_X47Y72.COUT    Tbyp                  0.083   counter<4>
                                                       counter_LPM_COUNTER_1__n0000<4>cy
                                                       counter_LPM_COUNTER_1__n0000<5>cy
    SLICE_X47Y73.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<5>_cyo
    SLICE_X47Y73.COUT    Tbyp                  0.083   counter<6>
                                                       counter_LPM_COUNTER_1__n0000<6>cy
                                                       counter_LPM_COUNTER_1__n0000<7>cy
    SLICE_X47Y74.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<7>_cyo
    SLICE_X47Y74.COUT    Tbyp                  0.083   counter<8>
                                                       counter_LPM_COUNTER_1__n0000<8>cy
                                                       counter_LPM_COUNTER_1__n0000<9>cy
    SLICE_X47Y75.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<9>_cyo
    SLICE_X47Y75.COUT    Tbyp                  0.083   counter<10>
                                                       counter_LPM_COUNTER_1__n0000<10>cy
                                                       counter_LPM_COUNTER_1__n0000<11>cy
    SLICE_X47Y76.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<11>_cyo
    SLICE_X47Y76.COUT    Tbyp                  0.083   counter<12>
                                                       counter_LPM_COUNTER_1__n0000<12>cy
                                                       counter_LPM_COUNTER_1__n0000<13>cy
    SLICE_X47Y77.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<13>_cyo
    SLICE_X47Y77.COUT    Tbyp                  0.083   counter<14>
                                                       counter_LPM_COUNTER_1__n0000<14>cy
                                                       counter_LPM_COUNTER_1__n0000<15>cy
    SLICE_X47Y78.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<15>_cyo
    SLICE_X47Y78.COUT    Tbyp                  0.083   counter<16>
                                                       counter_LPM_COUNTER_1__n0000<16>cy
                                                       counter_LPM_COUNTER_1__n0000<17>cy
    SLICE_X47Y79.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<17>_cyo
    SLICE_X47Y79.COUT    Tbyp                  0.083   counter<18>
                                                       counter_LPM_COUNTER_1__n0000<18>cy
                                                       counter_LPM_COUNTER_1__n0000<19>cy
    SLICE_X47Y80.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<19>_cyo
    SLICE_X47Y80.COUT    Tbyp                  0.083   counter<20>
                                                       counter_LPM_COUNTER_1__n0000<20>cy
                                                       counter_LPM_COUNTER_1__n0000<21>cy
    SLICE_X47Y81.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<21>_cyo
    SLICE_X47Y81.COUT    Tbyp                  0.083   counter<22>
                                                       counter_LPM_COUNTER_1__n0000<22>cy
                                                       counter_LPM_COUNTER_1__n0000<23>cy
    SLICE_X47Y82.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<23>_cyo
    SLICE_X47Y82.COUT    Tbyp                  0.083   counter<24>
                                                       counter_LPM_COUNTER_1__n0000<24>cy
                                                       counter_LPM_COUNTER_1__n0000<25>cy
    SLICE_X47Y83.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<25>_cyo
    SLICE_X47Y83.COUT    Tbyp                  0.083   counter<26>
                                                       counter_LPM_COUNTER_1__n0000<26>cy
                                                       counter_LPM_COUNTER_1__n0000<27>cy
    SLICE_X47Y84.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<27>_cyo
    SLICE_X47Y84.COUT    Tbyp                  0.083   counter<28>
                                                       counter_LPM_COUNTER_1__n0000<28>cy
                                                       counter_LPM_COUNTER_1__n0000<29>cy
    SLICE_X47Y85.CIN     net (fanout=1)        0.000   counter_LPM_COUNTER_1__n0000<29>_cyo
    SLICE_X47Y85.CLK     Tcinck                0.449   counter<30>
                                                       counter_LPM_COUNTER_1__n0000<30>cy
                                                       counter_LPM_COUNTER_1__n0000<31>_xor
                                                       counter_31
    -------------------------------------------------  ---------------------------
    Total                                      2.741ns (2.377ns logic, 0.364ns route)
                                                       (86.7% logic, 13.3% route)






Looks like a 32 bit counter hits 360 MHz, in a -11, with preliminary
speed files. Gotta love the 41.5 ps/bit carry chain.




On 03 Sep 2004 15:40:35 -0700, in comp.arch.fpga Eric Smith wrote:
>Philip Freidin <philip@fliptronics.com> writes:
>> Some of the manuals are single page PDFs, that point you to
>> the web site to get the real thing.
>
>Ugh!  I always hate that sort of thing.  CDs are cheap, they should
>include the real docs.  (It's all well and good to suggest looking at
>the web site for updates.)

This is clearly not a CD issue. Most of the manuals are included.
The ones that were stubbed, are the ones that were obviously not
ready at the time they had everything else ready to commit to CD.

These are basically the Virtex-4 library guides.

You can get them here:

   http://www.xilinx.com/support/sw_manuals/xilinx6/download/

>What happens in five years when a customer needs you to revise an
>old design?  You discover that Foundation ISE 11.2 doesn't support
>the old parts, or that for some reason the old design doesn't build
>right with it, so you get out your old CD of ISE 6.3.  And then
>discover that you don't have the actual documentation.

Well, I'm sure they will be in the 6.3.n sub release, and for older
versions of the software, you can go here:

   http://www.xilinx.com/support/software_manuals.htm

or

   http://www.xilinx.com/support/software_manuals_archive.htm

for even older stuff.

Philip

Philip Freidin
Fliptronics

Article: 72840
Subject: Re: Spartan 3 Starter Kit and ISE WebPACK
From: "Neeraj Varma" <neeraj_varma@yahoo.invalid>
Date: Sat, 4 Sep 2004 15:06:35 +0530
Links: << >>  << T >>  << A >>
> Is this 60-day license also a time-based license (TBL)?

I think the eval version is a time-out license, i.e. it stops working after
60 days...unlike the purchased ISE-FND, which is a TBL which provides for
archival use...and should not be used for new designs after 12 months unless
you renew the TBL



Article: 72841
Subject: Re: spartan3 pci above 33MHz
From: news@sulimma.de (Kolja Sulimma)
Date: 4 Sep 2004 13:26:23 -0700
Links: << >>  << T >>  << A >>
colin_toogood@yahoo.com (colin) wrote in message news:<885a4a4a.0409030335.2914c7ea@posting.google.com>...
> Hi all
> 
> I am interfacing a spartan 3 to a device that happens to use PCI. As
> the two devices will be about an inch apart with a point to point bus
> I'm curious about the right buffer to instantiate, particularly as
> bandwith calculations suggest that I need to run this bus at about
> 50MHz and the datasheet says that only pci_3v_33 exists in the IOB
> when pci_3v_66 exists for virtex 2.

Interestingly enough table 20 in this datasheet lists PCI66 for
spartan-3:
http://www.xilinx.com/bvdocs/publications/ds099-3.pdf

Also, PCI is specified for rather high bus loads and wire length. With
a single load and 1cm of wiring you should be able to run a pci33 core
with pci33_3 I/O at 50MHz.

My PCI core even worked in all our systems when I removed the timing
constraints which caused it to miss the specification by 8ns.

Kolja Sulima

Article: 72842
Subject: more than one clock
From: Simon <news@gornall.net>
Date: Sun, 05 Sep 2004 09:27:54 GMT
Links: << >>  << T >>  << A >>
Hi all,

Up until now, everything I've done has been synced to a single clock 
running around the FPGA. I now want to add a hardware divider (64 or 32 
bit dividend, 32 bit divisor) as a peripheral to the CPU, and it's going 
to be s...l...o...w - still faster han doing it in s/w of course :-)

A nice way to speed it up then would be to clock the divider circuit at 
a multiple of the rest of the CPU... Now I've read of things like 
'metastability' and advice to 'never use gated clocks' and such, so I 
was wondering if the following would be safe if the divider clock is 
running at M times the cpu clock (using a DCM) ?

clock  action
0      cpu writes dividend & divisor to divider module input ports
+1     cpu sets the 'go' input to divider high and waits for 'rdy'

+0.x   divider starts (N internal cycles) to perform division
+0.N   divider writes result to module output port
+0.M   divider writes 'rdy' to module output

+1     cpu reads result from divider, sets 'go' signal low.
+1.x   divider sets 'rdy' low since 'go' has gone low

The syntax for the clock here is that numbers before the '.' represent 
CPU clocks, numbers after represent divider clocks. The 'x' in stages 3 
and 7 just represents the fact that the divider clock may be a few 
periods ahead (in internal cycles) of the cpu clock - not really 
important, also the syntax '+0.N' really means +(N/M).(N%M) since N/M is 
highly likely to be >1...

Since the divider waits for M internal clocks (1 whole cpu clock) after 
writing the result and before writing 'rdy', doesn't that mean the 
result will be stable before the cpu reads it ? Is M clocks delay 
sufficient ? Would less do ?

Or is the whole idea a complete idiocy and should I scuttle back to 
completely synchronous designs [grin] ?

Thanks in advance for any help :-)

Simon.

Article: 72843
Subject: Re: CPLD : Is there a way
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 05 Sep 2004 21:44:43 +1200
Links: << >>  << T >>  << A >>
Lolotheguru wrote:
> Is there a way to get the schematics of the desing out of the .JED file !
> Is it possible ?

Yes.

> Thanks and best regards

A more usefull question, is : 'is it practical?'

You should specify which CPLD, and what other source codes you have
from this project.

For simpler devices JED2EQN programs exist, and the IC vendors may
have internal use JED to EQN - for these you will need to prove
ownership of the JED file, and have a credible story as to how
you find yourself in the situation where this is necessary.

Once you think you have it right, you should be able to prove that.
Test vector support can help here.

-jg


Article: 72844
Subject: Re: more than one clock
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 05 Sep 2004 11:07:14 GMT
Links: << >>  << T >>  << A >>
On Sun, 05 Sep 2004 09:27:54 GMT, Simon <news@gornall.net> wrote:
>Hi all,

Hi Simon,

>Up until now, everything I've done has been synced to a single clock 
>running around the FPGA.

Living a clean and pure life.

>I now want to add a hardware divider (64 or 32 
>bit dividend, 32 bit divisor) as a peripheral to the CPU, and it's going 
>to be s...l...o...w - still faster han doing it in s/w of course :-)
>
>A nice way to speed it up then would be to clock the divider circuit at 
>a multiple of the rest of the CPU... Now I've read of things like 
>'metastability' and advice to 'never use gated clocks' and such, so I 
>was wondering if the following would be safe if the divider clock is 
>running at M times the cpu clock (using a DCM) ?

Unless your CPU is really slow for some reason, I would expect the
max clock rate that your divider circuit to be similar to the max
clock rate of your CPU. Both tend to be dominated by carry chains,
add/sub in the CPU, and sub/compare in a divider.

Anyway, your description of passing data back and forth between the
CPU and divider is reasonable, except you are missing a pair of
synchronizers. These are typically a pair of flipflops, so you are
off by 4 flipflops.

If your want to read about metastability and synchronizers, I
recommend:

   http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

If you run the two sections of your design at different clock rates,
although there are special cases where it can be made to work if the
clocks are phase locked (with perhaps a DCM), there are difficulties
related to clock skew and jitter that may conspire to defeat you any
way.

It is far easier to just say that the clocks are asynchronous, and
then use standard techniques (synchronizers) to deal with it.

Lets look at your plan:

>clock  action
>0      cpu writes dividend & divisor to divider module input ports
>+1     cpu sets the 'go' input to divider high and waits for 'rdy'

Good. No race condition here, since data is guaranteed stable before
you set the GO signal. 

>+0.x   divider starts (N internal cycles) to perform division

So this is where you need the first synchronizer. The CPU GO bit
should feed a two stage synchronizer (two FFs), both of which are
clocked by the divider clock. Otherwise the GO signal arrives
asynchronously in the divider's clock domain, and metastability or
race conditions could occur. Synchronizing the GO signal reduces
the probability of problems. Not to zero, but with good synchronizer
design, vanishingly rare (like once per megayear).

You don't need any synchronization on the data, since it was all set
up prior to the GO signal, so it is guaranteed stable by the time
the divider trys to look at it after it receives the synchronized
version of the GO signal.

>+0.N   divider writes result to module output port
>+0.M   divider writes 'rdy' to module output

Good. No race condition here, since data is guaranteed stable before
you set the RDY signal.

>+1     cpu reads result from divider, sets 'go' signal low.

Same story as above. The RDY signal needs to synchronized with a two
stage synchronizer, that is clocked by the CPU's clock. 

>+1.x   divider sets 'rdy' low since 'go' has gone low
>
>The syntax for the clock here is that numbers before the '.' represent 
>CPU clocks, numbers after represent divider clocks. The 'x' in stages 3 
>and 7 just represents the fact that the divider clock may be a few 
>periods ahead (in internal cycles) of the cpu clock - not really 
>important, also the syntax '+0.N' really means +(N/M).(N%M) since N/M is 
>highly likely to be >1...

Right. The '0' is really several cycles later for the CPU. The exact
number doesn't really matter, as you have it waiting for the synchronized
version of the RDY signal.

>Since the divider waits for M internal clocks (1 whole cpu clock) after 
>writing the result and before writing 'rdy', doesn't that mean the 
>result will be stable before the cpu reads it ? Is M clocks delay 
>sufficient ? Would less do ?

The M internal clocks avoids a race condition, by guaranteeing that
the data is stable before RDY is sent, but the CPU still needs to see
RDY in its own clock domain, so it must be synchronized.

>Or is the whole idea a complete idiocy and should I scuttle back to 
>completely synchronous designs [grin] ?

Nope. This is fine, and you got it mostly right. Add 4 FFs, and you
should have a fine reliable system.

Next project, add floating point multiply, divide, add, subtract.

>Thanks in advance for any help :-)
>Simon.

Hope this helps.
Philip



Philip Freidin
Fliptronics

Article: 72845
Subject: Re: vga to ethernet converter
From: "INS122595" <walter@chasque.apc.org>
Date: Sun, 5 Sep 2004 09:38:31 -0300
Links: << >>  << T >>  << A >>
We done similar projects, the critical point is if many VGA standard need be
supported

Walter


"Rune Christensen" <rune.christensen@adslhome.dk> a écrit dans le message de
news:41384139$0$195$edfadb0f@dread12.news.tele.dk...
> "Ian"
> <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com>
> skrev i en meddelelse news:Q0qZc.555637$6p.104886@news.easynews.com...
> > On Wed, 1 Sep 2004 12:36:04 +0200, Rune Christensen
> <rune.christensen@adslhome.dk> wrote:
> >
> > >Does anyone know if it's possible to build a VGA to ethernet converter?
A
> > >device that converts a VGA signal to a digital videostream.
> > >I want to be able to operate a computer from a remote position also
when
> the
> > >computer boots. So I will be able to change bios settings, starting
mode
> of
> > >Windows, etc.
> >
> > Some "server management" cards do just this. Needs to either snoop the
bus
> for VGA
> > accesses or fully emulate a VGA adapter (i.e. they /are/ the VGA adapter
> for the
> > machine). Quite expensive to buy, quite hard to make...
> >
> >
> > -- 
> > Ian
> >
> > 'Milk below!'
>
> I think that this must the easiest solution to the problem. Create a VGA
> card that transfer the screen to ethernet instead of a screen. Maybe a PCI
> FPGA card could be used to do this.
>
> To the people on comp.arch.fpga have anyone tried to create a VGA card on
a
> PCI FPGA card?
>
> Thanks
> Rune Christensen
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.746 / Virus Database: 498 - Release Date: 31-08-2004
>
>



Article: 72846
Subject: Re: more than one clock
From: Simon <news@gornall.net>
Date: Sun, 05 Sep 2004 13:20:04 GMT
Links: << >>  << T >>  << A >>
Philip Freidin wrote:

First off, Philip - thanks very much for the help - it's clear to me now 
why you need the synchronizers :-)

> Unless your CPU is really slow for some reason, I would expect the
> max clock rate that your divider circuit to be similar to the max
> clock rate of your CPU. Both tend to be dominated by carry chains,
> add/sub in the CPU, and sub/compare in a divider.

The CPU module itself is happy to run at ~70MHz, but when I wrap the 
rest of the SOC around it, it drops right down to ~35 MHz, so it is 
pretty slow :-( I've yet to convince myself of the reason for the 
slowdown (I've thought it was lots of things, worked around the issue 
and not fixed the problem!). Now that Jim Wu has shown me how to do
hierarchical floorplanning, I might be able to make the mess that is
my cpu a little more logically-laid-out, which might help :-)

I thought I might be able to get 2x (hey, maybe 3x :-) performance from 
the divider module if it's running as a separately-clocked domain 
loosely coupled to the main CPU.

I'll bet there are some "old-timers" looking at those figures and 
thinking to themselves, "what's the problem ? Only 70 MHz ? I can do 
that in my sleep!" [grin]

> If your want to read about metastability and synchronizers, I
> recommend:
> 
>    http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

Wow! Lots of info - excellent stuff :-)

> 
> Next project, add floating point multiply, divide, add, subtract.

I've just spent the last 3 of the last 4 days trying to port gcc to the 
architecture - is that one beast of a program! Instead I settled for 
'lcc', and got it working in half a day :-) I ended up having to rewrite 
my assembler quite a bit to cope with the degenerate assembly syntax 
that 'lcc' produces, and along the way it turned into a linker rather 
than an assembler ('as' is now implemented with 'cp' :-). Now I can type 
'lcc file.c -o file.out' and end up with a Motorola S-record file ready 
for upload.

What's next to do:

  o First, redo the internals a bit, so the data bus is only driven
    when necessary (at the moment it's all the time, and I want
    peripherals to be master-capable on the SOC - even to have more
    than one CPU sharing the SOC bus). This implies a priority
    controller, and bus-request lines etc.

  o After that, I want more interrupt control (a bit like the m68k
    'trap' or arm 'swi' calls, so the CPU can raise an interrupt
    for itself when it gets a bus error, for example). The idea is
    that any peripheral (including a cpu) can send a (32 bit)
    message to any other, the address defining the message type,
    the data-bus defining the message value. Eg: network controller
    peripheral buffer is 3/4 full, so it sends IRQ to an OS driver
    on a CPU to read the data and create some more space. Traps,
    interrupts and signals all with the same technique :-)

  o Next up is an SDRAM controller (although I ought to be able to
    take one of the existing Xilinx ones), because at the moment,
    the whole thing is running out of 4 blockrams. At that point,
    it'll probably become important to have a pipelined arch. just
    to hide the IF delay and load/store times.

  o Then I want an instruction cache, probably not a data cache
    (again due to the desire for multiple processors on the same
    SOC, coherency would become an issue without a bus-snooping
    protocol).

  o When all that's in place, I'll want to think about an RTOS,
    although I'll probably port freertos or something rather than
    write my own. Of all the tasks in the whole project, this is
    the only one I've had some experience with! [grin]

  o Finally, I can start to think about adding floating-point
    support :-)


So, lots to keep me busy :-)

Simon.

Article: 72847
Subject: Re: spartan3 pci above 33MHz
From: colin_toogood@yahoo.com (colin)
Date: 5 Sep 2004 06:28:53 -0700
Links: << >>  << T >>  << A >>
news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0409041226.6721b2bf@posting.google.com>...
> colin_toogood@yahoo.com (colin) wrote in message news:<885a4a4a.0409030335.2914c7ea@posting.google.com>...
> > Hi all
> > 
> > I am interfacing a spartan 3 to a device that happens to use PCI. As
> > the two devices will be about an inch apart with a point to point bus
> > I'm curious about the right buffer to instantiate, particularly as
> > bandwith calculations suggest that I need to run this bus at about
> > 50MHz and the datasheet says that only pci_3v_33 exists in the IOB
> > when pci_3v_66 exists for virtex 2.
> 
> Interestingly enough table 20 in this datasheet lists PCI66 for
> spartan-3:
> http://www.xilinx.com/bvdocs/publications/ds099-3.pdf
> 

Thanks for taking the trouble

Note to self
ALLWAYS check that I am using the latest datasheet before posting to
the world like a right plonker!

In my defence the new datasheet is only 2 weeks old. I only downloaded
the datasheet about 3 weeks ago and searching for "PCI" found no
reference to 66.
It now finds 3, none of which are explicitly in the Revision History!

> Also, PCI is specified for rather high bus loads and wire length. With
> a single load and 1cm of wiring you should be able to run a pci33 core
> with pci33_3 I/O at 50MHz.
> 
Hence my question over which IOBs people use on the single load
signals. If XILINX provide the right IBIS models I will see if the
PCI33 IOB uses less power and hence easier decoupling etc.

> My PCI core even worked in all our systems when I removed the timing
> constraints which caused it to miss the specification by 8ns.
> 
> Kolja Sulima

Article: 72848
Subject: PDSPs vs FPGAs for DSP
From: "Orbit" <orbit@dunno.net>
Date: Sun, 5 Sep 2004 13:52:21 GMT
Links: << >>  << T >>  << A >>
Hi,

I am reading Uwe Meter-Baese's book "DSP with FPGAs" and am trying to gain
some perspective here. FWIW, I develop embedded apps on the Atmel 8 bit AVR
platform with CodeVision C compiler.

What are the pros and cons of going PDSPs vs. FPGAs to implement DSP for my
8 bit apps?

This book favors Altera and VHDL ( which I don't even know)

Help me out here...

Article: 72849
Subject: Re: 1GHz FPGA counters
From: Thomas Rudloff <thomas_rudloff@gmx.net>
Date: Sun, 05 Sep 2004 15:55:12 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

>Here are my thoughts for a fairly simple implementation. If I recall, the
>original post asked for a report of the arrival time of input pulses (let's
>assume rising edges) with a resolution of 1 ns.
>
>I suggest a synchronous design running at 250 MHz (synchronous counter,
>transfer to BlockRAM etc) augmented with a small "prescaling" front-end.
>The input line gets clocked into four flip-flops in parallel, each clocked
>on a different quadrant of the 250 MHz clock. Using the flip-flop clock
>polarity option, this requires only two global lines driven by one DCM.
>
>Now that we have captured the input edge in 4 flip-flops, we have to figure
>out where it was captured first. For that, we must move the four staggered
>signals into the same clock domain, and we should move any signal only by a
>quarter clock per step (to avoid excessively tight delay requirements). This
>takes half a dozen flip-flops, followed by a 1-of-4 decoder that defines the
>position of the leading edge, and is used as the two LSBs for the timer.
>
>This circuit would have problems if two pulses arrive within 4 ns, but I
>hope that is physically impossible.
>
>Counter trickery is really not necessary. It's all synchronous to 250 MHz.
> It's only the sub-one-nanosecond resolution that requires some trickery.
>
>Peter Alfke
>
>  
>
Hi,

I am currently developping the oposite and came up that it might not be 
good to use an FPGA because of
routing delays that might no be equal on all paths. My suggestion is to 
use a cypress Roboclock to get
four phases and use a CPLD to modulate the pulse. The CPLD path delays 
are expected to be allmost
the same as long as you take care not to use more than five PTs.

So in my application I have a 100MHz clock with four phases (1.25ns 
increment) and the FF triggering
at rising and falling edges giving 800MHz resolution.

My interrest is to know whether I can archive the same precission 
(<100ps) in an FPGA?

Regards
Thomas

PS: It is a PWM modulator for a digital amplifier.



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