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
Thank you. -Sue Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23526
Thank you. -Sue In article <h4G$vNA8IiW5EwLN@matter200.demon.co.uk>, dmac <dmac@cutme.matter200.demon.co.uk> wrote: > > <extract> > The digital Phase/Frequency Comparator is the same one shown in > Xilinx Application Note XAPP028 (Dec 2 1996) > http://www.xilinx.com/xapp/xapp028.pdf > <end> > > I think this is the one from Nestor's original post - author is Peter > Alfke - now where have I heard that name before :o) > > Dave > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23527
SteVe, (why the cap V?) The power estimator was verified against many actual customer designs so that the estimate was as good as we could get it. The rules of thumb approach that had been used was just too coarse, and the exact solution is unimportant due to the variations in the process, and so on. I have heard no complaints about its estimations, and have recommended it to many customers in order to help them with their power supplies, thermal management, and bypass capacitor requirements. Austin SteVe wrote: > Hello. > > I need a rough estimation of the power consumption of my design (the > target device is a Xilinx XCV400). I've found a web page > (http://www.xilinx.com/cgi-bin/powerweb.pl) with the Virtex Power > Estimator developed by Xilinx. Is there somebody who used it? Is it a > good choice? Or do you suggest another way to perform this estimation? > > Thanks, > SteVeArticle: 23528
The current crop of CPLD are not ideal for oscillators - too much gain/delay on pin=pin basis - this means it oscillates all right, but you can unplug the crystal :-) To construct a xtal osc, you need a 74HCU04 type gate, but you can get these as single gates in SOT23 region packages. Next you find that the sine wave from this needs squaring up, to drive the CPLD.. Philips have a 74HC9323A that is Osc+Small divider in SO8. Or use a XTAL module, and clock the CPLD from that. - jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 23529
Here is my code, however when I used Xilinx Foudation to synthesis it is
successful however with one warning Synthesizing... Warning L-1/C0 : #0
Warning: Latch inferred in design 'PWMv2' read with 'hdlin_check_no_latch'.
(HDL-307) Warning L-1/C0 : #0 Warning: The part has fewer I/O ports (125)
than that required by the design (129) (FPGA-EXTERNAL-impl-pins-less) 0
error(s) 2 warning(s) found Synthesis succesful (Warnings found)
When trying to create macro, it failed
Line 6
Wrong number of fields BUS
What is wrong thanks
--LIBRARY ieee;
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use ieee.std_logic_arith.all;
ENTITY PWMv2 IS PORT( frequency: in std_ulogic_vector(30 downto 0);
dutyratio: in std_ulogic_vector(30 downto 0); deadtime: in
std_ulogic_vector(30 downto 0); Control: in std_ulogic_vector(30 downto 0);
reset: in std_logic; clk: in std_logic; enable: in std_logic;
waveform1,waveform2: OUT std_logic ); END PWMv2;
ARCHITECTURE version2 OF PWMv2 IS
SIGNAL counter: integer; signal MaxDutyRatio: integer; signal
MaxDeadTime: integer; signal MaxFreq: integer; signal RealFreq :
std_ulogic_vector(30 downto 0); signal RealDutyRatio : std_ulogic_vector(30
downto 0); signal RealDeadtime : std_ulogic_vector(30 downto 0); signal
RealControl : std_logic;
BEGIN
CONV:process(RealDutyRatio,RealDeadTime,RealFreq) begin MaxDutyRatio <=
CONV_INTEGER(UNSIGNED(RealDutyRatio)); MaxDeadTime <=
CONV_INTEGER(UNSIGNED(RealDeadTime)); MaxFreq <=
CONV_INTEGER(UNSIGNED(RealFreq)); end process;
PWM_Gen: PROCESS (counter,enable,MaxDutyRatio,MaxDeadTime) BEGIN if
enable='1' then if counter < MaxDutyRatio then waveform1 <='1'; else
waveform1 <= '0'; end if; if counter< MaxDutyRatio+MaxDeadTime then
waveform2 <= '0'; else waveform2 <= '1'; end if; end if; END PROCESS
PWM_Gen;
Counter_Gen: process (clk,reset,enable,MaxFreq,RealControl)
variable UpOrDown : std_logic; -- Go Up or Go Down
begin if enable='1' then if reset= '1' then counter<= 0; UpOrDown :=
'0'; elsif rising_edge(clk) then if RealControl='0' then --Synchronous
waveform if counter= MaxFreq or counter = 0 then UpOrDown := not UpOrDown;
end if; if UpOrDown='1' then counter <= counter + 1; --Waveform goes up
else counter <= counter - 1; end if; else -- Asynchronous waveform
counter <= counter + 1; if counter = MaxFreq then counter <= 0; end if;
end if; end if; end if; end process Counter_Gen;
Freq_Gen:process(counter,reset,enable,frequency,dutyratio,de
adtime,Control,RealControl,RealFreq) begin if enable='1' then if RESET='1'
then RealFreq <= frequency; RealDutyRatio <= dutyratio; RealDeadtime <=
deadtime; RealControl <= Control(0); else if RealControl='1' then if
counter=0 or counter=CONV_INTEGER(UNSIGNED(RealFreq)) then RealFreq <=
frequency; RealDutyRatio <= dutyratio; RealDeadtime <= deadtime;
RealControl <= Control(0); end if; else if counter=0 then RealFreq <=
frequency; RealDeadtime <= deadtime; RealDutyRatio <= dutyratio;
RealControl <= Control(0); end if; end if; end if; end if; end process
Freq_Gen; END version2;
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23530Hey All, I'm currently working on a block for this telco chip which will act as a test generator. The module can be selected to put out logic 1, logic 0, or Pseudo Random data (serially for all cases, BTW). The first 2 are very easy, and thanks to the Xilinx app note, the PRN Generator seems to be easy as well.... The problem I'm having is that the module will be checking a stream to compare it to the original at a later point in time. How does one go about synchronizing the incoming serial stream [receiver] (the PRN case) to its generator for comparison [I will be keeping an error count, but as stated, I can't quite think of a way for it to "Hey! Start checking, this is the PSN stream"] Any code/links/discussion is appreciated. Thanks, DaveArticle: 23531
Hello Dave; I posted an answer at about 20 march 1999 under thread "Re: Bit Error Rate Test". If you can not find it in deja.com, let me know and I will mail it to you or repost again. Juan-Luis Lopez SpainArticle: 23532
Turns out, this is really simple to do, assuming the generator and checker of the PRN stream is a serial design. This is true in all cases I know of, as it is an LFSR generator. Your checker is the same as teh generator, and then you just match the received stream against the locally generated 'expected' stream. To synchronize them, put a mux in front of the local generator's input point ( the point in the shiftregister where the xor-ed taps feed back in, the LSB), and when you want to synchronize to the incoming stream, just feed it into the shiftregister for as many clocks as there are bits in the shiftregister. Once this is done, flip the mux back to doing LFSR stuff, and it should now be in sync with the incomming data. So for a 16 bit LFSR PRN generator, it will take 16 cycles to sync to the incomming test stream. The only problem is if there is an error in the incomming stream while loading the local generator. If there is, then you will get insanely high error counts. If there was no error, then you will get the, hopefully low, expected error rates. For extra smartness, you can continue to load the local shiftregister while monitoring what the local generator input would be (the output of the xor gate that is being ignored), and figure what the reported error rate would be if not in sync-ing mode. then switch from sync-ing to checking when teh error rate indicates you are in sync. Philip Freidin In article <UPs65.7579$W35.138494@news20.bellglobal.com>, Xanatos <deletemeaoe_londonfog@hotmail.com> wrote: >The problem I'm having is that the module will be checking a stream to >compare it to the original at a later point in time. How does one go about >synchronizing the incoming serial stream [receiver] (the PRN case) to its >generator for comparison [I will be keeping an error count, but as stated, I >can't quite think of a way for it to "Hey! Start checking, this is the PSN >stream"] >Any code/links/discussion is appreciated. >DaveArticle: 23533
"Juan-Luis Ląpez RodrĄguez" <jl.lopez@REMOVETHISieee.org> wrote in message news:395a6fd4_2@news.arrakis.es... > Hello Dave; > > I posted an answer at about 20 march 1999 under thread "Re: Bit Error Rate > Test". If you can not find it in deja.com, let me know and I will mail it to > you or repost again. > > Juan-Luis Lopez > Spain Hi Juan-Luis; Thanks for the reply. I can't seem to locate it on deja, so if you email it to me, please do. (Or post it) Email: aoe_londonfog@hotmail.com Thanks again, DaveArticle: 23534
Bryan Williams <nospamformethanks@nowhere.com> writes: >On Sun, 25 Jun 2000 17:33:57 +0200, Claas Richter <clri@gmx.de> wrote: >>Hello! >> >>Does anyone have any experience in the use of FPGAs for connecting to >>the IDE-Bus? >> >>Or has anybody implemented an IDE/ATA-Bus-Interface for FPGAs ?? >>I need it to read and write to a harddisk. The IDE bus is really the AT/ISA data bus extended through the cable, with the IO address decoded. It is a little, but just a little, more than that. That said, the other posts should supply the details. -- glenArticle: 23535
> For extra smartness, you can continue to load the local shiftregister > while monitoring what the local generator input would be (the output of > the xor gate that is being ignored), and figure what the reported error > rate would be if not in sync-ing mode. then switch from sync-ing to > checking when teh error rate indicates you are in sync. Check out the term Self Synchronizing Scrambler in the communications literature or text. ATM over SONET uses one. It's one of those "of course" ideas after you see it. The idea is to leave your mux in the load position all the time. The disadvantage is that a single error bit turns into a multiple bit error. (I think you get the CRC generator polynomial out.) Suppose you setup a system using a Self Synchronizing Scrambler and send a data pattern of all 0s. Now the receiver knows what the data pattern should be but the bit pattern on the link will be the output of the LFSR. If the error rate is low, you can count error bits and divide by the number of 1 bits in the polynomial. -- These are my opinions, not necessarily my employers. I hate spam.Article: 23536
Hi We have exactly the same problem. There doesn't appear to be a solution, and we still run dual boot PCs with NT and 3.11 on them to support our designs in the XC5200 series. I did look at migrating the designs to the Spartan family but I seem to need a an XCS20 to hold what fits comfortably in an XC5204, so there was not cost saving to be had. If you are using Foundation, whatever you do, don't use the Foundation Project > copy feature in 1.5i to take a copy of your Foundation 6.0 format project. I did this to see how 1.5i would handle an existing design. While it copies over the top level schematics to a new project directory, it leaves any custom macros and libraries in the old project directories but converts them to the 1.5i format =- net result when you go back to Foundation 6.0 to do some work, all your own user defined libraries are unable to be read, though the standard Xilinx libraries are unaffected. (thank god for back ups.) Jeff Graham Rascal wrote: > > Has anyone of you ever tried to implement a XC5202/5206 device with > Foundation 2.1i ( or 1.5, too) ? The software seems to have BIG problems in > routing designs based on these devices; the old XACT router, running with > Windows 3.11, on the other hand, could manage the same design without > excessive effort. > Actually, I still have to use that older implementation software (and then > keep a dedicated PC with Windows 3.11 installed on it) to develop/update my > XC5200 based projects, and this isn't really that comfortable. F2.1i > tools,in most cases, can't succeed in the PAR step for simple designs, too. > I talked to two Xilinx field application engineers about this matter. One of > them told me that this is a known problem of implementation tools based on > M1 engine, so I have necessarily to use old XACT for XC5200 devices. The > other one told me that F2.1 router is actually slightly worse than XACT for > XC5200 but should work anyway: in my case the problem should reside on > netlist generation. > Does anyone has any additional information or, better, a solution ? > > Thanx in advance.Article: 23537
Hello, is there some free PCI 33/32 core available I'm not aware of, besides * the comp.arch.fpga faq * Xilinx * Altera * Cypress * opencores.org Thanks ArminArticle: 23538
I have made big gate-array designs and do now a design in
VertexE 1000
I see 3 main-problems.
a) missing timing-closure
b) no good floor-planner
--> unpredictable results at synthese + fitteing,
--> Loss of Speed ( design brings only 50-75% of possible speed )
--> chaotic placing of functions
c) no incremental synthesis and fitting.
--> so the synthese takes 80min,
the fitter takes 80 h , with incremental
optimisation and 5 attempts
and some lower prior problems.
d) constrainin of multi-cycle paths
--> unnecessary Gates
e) hierarchical floorplanning
you typically have about 50 instances to plan
f) time bugeding at bottom- up synthese
i know a lot of good developers work on these problems,
but they have to solve them very soon, so you have a
good chance for a high - speed design in a VertexE 2000.
MfG E.Blaschek
Article: 23539
Dear Dave;
While I try to find the old posting ;-) you can look at an example of this
within my final thesis at
http://www.arrakis.es/~jl.r/pfc/index.htm
The thesis described a test instrument for E1 (2048kbit/s) telecomm signals,
transmitter and receiver. The design was fully tested and 100% working.
For historical reasons is password protected, but username="user" and
password "1234" will work.
Sorry, the body of the document with all the explanations is in spanish, but
you can look at some of the FPGA schematics at
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__T_PRBS (PSN generator)
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__R_PRBS (PSN receiver)
The PRBS signal was one of the specified in UIT-T recommendation O.152,
length 2^11-1.
D is the input data
CK is the input clock
CE is the input clock enable
D_SYNC is the output that shows the synchronism state of the receiver.
Low level means synchronised, high means out of synch.
E_BIT is the output bit error signal (to error counter)
I1S is the input 1Hz pulse to reset error integration for loss of synch.
Has to be in high state only one bit time.
Please note that I had lots of free space within the FPGA, so the error
counter for the loss of sync decision (L21) was implemented in the FPGA. A
more usual aproach is to implement it in software, sharing the values readed
at the bit error counter attached externally to E_BIT output. The reason is
that loss of sync needs a long time error integration, and a long counter in
order to avoid overflow.
This circuit is free from error multiplication problem while measuring and
from false synch due to errors while synchronising. It is also immune to
false synch when receiving "all zeros" or "all ones" input signals
(depending on the polarity of the PRBS) thanks to L2. It does not loss synch
in presence of bursts of errors.
You can decrease the probability of false synch in presence of random input
signals by making L22 larger. The probability of the circuit shown were
1/(2^5 -11).
Some of the schematics were commented in english, but the above ones had no
comments at all :-(
Hope this helps in the meantime.
Juan-Luis Lopez
Spain
Article: 23540
Dear Dave;
While I try to find the old posting ;-) you can look at an example of this
within my final thesis at
http://www.arrakis.es/~jl.r/pfc/index.htm
The thesis described a test instrument for E1 (2048kbit/s) telecomm signals,
transmitter and receiver. The design was fully tested and 100% working.
For historical reasons is password protected, but username="user" and
password "1234" will work.
Sorry, the body of the document with all the explanations is in spanish, but
you can look at some of the FPGA schematics at
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__T_PRBS (PSN generator)
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__R_PRBS (PSN receiver)
The PRBS signal was one of the specified in UIT-T recommendation O.152,
length 2^11-1.
D is the input data
CK is the input clock
CE is the input clock enable
D_SYNC is the output that shows the synchronism state of the receiver.
Low level means synchronised, high means out of synch.
E_BIT is the output bit error signal (to error counter)
I1S is the input 1Hz pulse to reset error integration for loss of synch.
Has to be in high state only one bit time.
Please note that I had lots of free space within the FPGA, so the error
counter for the loss of sync decision (L21) was implemented in the FPGA. A
more usual aproach is to implement it in software, sharing the values readed
at the bit error counter attached externally to E_BIT output. The reason is
that loss of sync needs a long time error integration, and a long counter in
order to avoid overflow.
This circuit is free from error multiplication problem while measuring and
from false synch due to bit errors while synchronising. It is also immune to
false synch when receiving "all zeros" or "all ones" input signals
(depending on the polarity of the PRBS) thanks to L2. It does not loss synch
in presence of shorts bursts of errors.
You can decrease the probability of false synch in presence of random input
signals by making L22 larger. The implementation shown has a probability of
1/(2^5 -11) for each 2^5 (32) bits received in sequence.
Some of the schematics were commented in english, but the above ones had no
comments at all :-(
Hope this helps in the meantime.
Juan-Luis Lopez
Spain
Article: 23541I think Lucent offers a FPGA with an embedded PCI core -- If I recall correctly it is in the Series 3+ devices. Hope this helps. -Jeff ----------------------------------------------------------- Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.comArticle: 23542
Hi Folks, Having a particular FPGA in hand (with a specific speed grade), How can someone assess the performance of a particular design. In other terms, how can you know the maximum obtainable speed for a particular design. The question might seem vague but I will illustrate: Say you want to do a bit serial convolution on an XC4000 chip. What is the best speed you can get. I can see that for a heavily pipeline design, you can assume that the maximum delay is the CLB delay (FF or LUT). How about the routing? Is it fair to assume that in a good design the routing delay is equal to the logic delay and so You can say that the best period time (the minimum) you can get is 2*CLB_delay?? Any input is much appreciated. Cheers.Article: 23543
>We have exactly the same problem. There doesn't appear to be a solution, >and we still run dual boot PCs with NT and 3.11 on them to support our >designs in the XC5200 series. .... >libraries are unable to be read, though the standard Xilinx libraries >are unaffected. (thank god for back ups.) > I've experimented that, too ! Thank god for back ups. I've also found out that in F1.4 there is the option to archive a project but ther isn't any to restore it. Again, thank god for back ups. Thanks for your reply, anyway.Article: 23544
Thanks Philip, Hal and Juan! I think I have a good basis of what to do next. Now is just a matter of implementing it ;) Cheers, DaveArticle: 23545
Hello, When PCI slots are unused, some motherboards disable the PCI CLK to that particular slot. (I just learned this on the pcisig.com mail reflector) I understand they use the 'Card Present' signal to determine if the slot is populated. Is it possible that some mother boards incorrectly assume that a slot is empty if it contains a FPGA based contoller which takes some time to initialize after power up. Sincerely Daniel DeConinckArticle: 23546
Route delay = CLB setup time would be a good top speed estimate for the Xilinx parts. If you have the tools, I would enter a small design and compile it. The static timing report tool will then tell you the top speed. "Jimmy" <j_robby@hotmail.com> wrote in message news:8jfd9d$o58$1@news.qub.ac.uk... > Hi Folks, > > Having a particular FPGA in hand (with a specific speed grade), How can > someone assess the performance of a particular design. In other terms, how > can you know the maximum obtainable speed for a particular design. The > question might seem vague but I will illustrate: > Say you want to do a bit serial convolution on an XC4000 chip. What is the > best speed you can get. I can see that for a heavily pipeline design, you > can assume that the maximum delay is the CLB delay (FF or LUT). How about > the routing? Is it fair to assume that in a good design the routing delay is > equal to the logic delay and so You can say that the best period time (the > minimum) you can get is 2*CLB_delay?? > > Any input is much appreciated. > > Cheers. > >Article: 23547
In article <395AF87F.D4C44FDB@stud.uni-karlsruhe.de>, Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote: > Hello, > > is there some free PCI 33/32 core available I'm not aware of, besides > > * the comp.arch.fpga faq > * Xilinx > * Altera I didn't know Xilinx gives away their PCI core. Last time I checked they wanted $15K + royaltis ... Same for Altera - don't remember the price .... Would love to see a *decent* e.g. synthesisable and complient free core !!! > * Cypress > * opencores.org > > Thanks > Armin bkk Sent via Deja.com http://www.deja.com/ Before you buy.Article: 23548
This may give you an estimate for a "theoretical" speed, I would not use it for any design that I did not understand fully. Both the "one LUT" assumption and the "short routing delay" assumption will be invalidated by specific items in many designs. For example, if you are designing a finite state machine (FSM) to control some circuit, you may have too many inputs to a single state to be able to define the next state function in a single CLB (two linked LUTs). This often happens. Then if you have any long nets with high fan out, such as a clock enable, you may have to allow two or three LUT delays to distribute this signal. Pipelining can help, but it can not be used when you need to have feedback in the path, such as in a FSM. So it is best to know enough about your design to be able to at least determine the number of inputs to every logic function. Jimmy wrote: > > Hi Folks, > > Having a particular FPGA in hand (with a specific speed grade), How can > someone assess the performance of a particular design. In other terms, how > can you know the maximum obtainable speed for a particular design. The > question might seem vague but I will illustrate: > Say you want to do a bit serial convolution on an XC4000 chip. What is the > best speed you can get. I can see that for a heavily pipeline design, you > can assume that the maximum delay is the CLB delay (FF or LUT). How about > the routing? Is it fair to assume that in a good design the routing delay is > equal to the logic delay and so You can say that the best period time (the > minimum) you can get is 2*CLB_delay?? > > Any input is much appreciated. > > Cheers. -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23549
In my oppention, there is now good way to determin how fast a design might be able to run in a certain FPGA. You can do a WAG (Wild Ass Guess ;*) by doubling the CLB delay, but it will be very inaccurate. There are to many factors that will influence the delay. Even synthesis tools can not accuratley report the timing (however they are typically over conservative). If you have a havily pipelined design, it will help, but still not guarantee that it will run fast. If the routing is congested or you have large busses going across the chip, you will suffer ... Best is always trial and error, specially if you want to run really fast. I usually end up going through my design and replace as many obvious premitives as I can with coregen parts. That most of the time helps, specially if you have large databuses, you can keep the routing somewhat local on certain parts (muxes, adders etc.). Good Luck, bkk In article <8jfd9d$o58$1@news.qub.ac.uk>, "Jimmy" <j_robby@hotmail.com> wrote: > Hi Folks, > > Having a particular FPGA in hand (with a specific speed grade), How can > someone assess the performance of a particular design. In other terms, how > can you know the maximum obtainable speed for a particular design. The > question might seem vague but I will illustrate: > Say you want to do a bit serial convolution on an XC4000 chip. What is the > best speed you can get. I can see that for a heavily pipeline design, you > can assume that the maximum delay is the CLB delay (FF or LUT). How about > the routing? Is it fair to assume that in a good design the routing delay is > equal to the logic delay and so You can say that the best period time (the > minimum) you can get is 2*CLB_delay?? > > Any input is much appreciated. > > Cheers. > > Sent via Deja.com http://www.deja.com/ Before you buy.
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