Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 youArticle: 72826
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
Is there a way to get the schematics of the desing out of the .JED file ! Is it possible ? Thanks and best regardsArticle: 72828
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? MarkusArticle: 72829
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? > > MarkusArticle: 72830
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 WallaceArticle: 72831
> > 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/chipsArticle: 72832
>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
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 SumitArticle: 72834
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 FAXArticle: 72835
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: 72836SG 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. BenArticle: 72837
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: 72838Philip 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
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> 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 TBLArticle: 72841
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 SulimaArticle: 72842
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
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. -jgArticle: 72844
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 FliptronicsArticle: 72845
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
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: 72847news@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 SulimaArticle: 72848
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
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:
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