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
Heya, For the XC4000, It is said that any CLB can implement up to 9-input function This is possible since 1- each FMAP can implement any 4-input Logic function 2- HMAP can implement any 3-input Logic function Thus by combining 2FMAPs and HMAP, up to 4+4+1=9 input function can be delivred.i.e.ResFunc=3_func(4_func(a,b,c,d),4_func(e,f,g,h),I) But if a user has a 9-input function to implement, he really needs to identify what 4_func(a,b,c,d) , 4_func(e,f,g,h) and then 3_func to use.... Although i see it feasible, surely not straighforward ? any taught Now about the Virtex, it is said that each CLB can implement up to 19-input function. i Believe that this number has been deduced from 4+4+4+4(The 4 LUTs)+2(F5)+1(F6) but i don't think that this will be for any logical function, simply because F5,F6 are multiplexers and not 3-input function generator as Xc4000 HMAP so what is the maximum inputs functions that we can implement on Virtex CLB ?. is it 13 (4+3+3+3) -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 49601
Hal Murray wrote: > >> Didn't they "fix" that in some rev? > > > >Of the PCI spec of the Xilinx part ;-) > > I thought they updated the PCI spec to allow PLL clock buffers. > I might be thinking of something else. > IIRC what happened is that Intel defined something called the `Mobile Computing' spec. As part of this there's now a PCI stop-clock protocol. I *think* this has 2 parts: A PCI peripheral can inhibit the clock stop if it doesn't support it and there's time, when the clock starts again, for any DLL/PLL to re-lock. Dunno if this made it into the PCI 2.2 spec.Article: 49602
Hi,all
Recently I have to do a project which use altera'fpga. My system is
use epex200ke and a mcu and an ad6620. Our design is use mcu to set
the ad6620 to
work, and the mcu can read the register of ad6620.surely the fpga have
more function. my question is only about how can design the interface
about muc and ad6620. The mcu have ale, mcu_ad(7 downto 0)(bidir and
address/address) mcu_wr,mcu_rd;ad6620 have ad6620_cs,ad6620_add(2
downto 0),
ad6620_databus(7 downto 0)(bidir) ,ad6620_wr,ad6620_rd.
my question is any one can help me to check my code is right.Thanks a
lots.
here is my code about this.
library ieee;
use ieee.std_logic_1164.all;
entity interface is
port(
mcu_ad: inout std_logic_vector(7 downto 0);
mcu_wr: in std_logic;
mcu_rd: in std_logic;
ale : in std_logic;
ad6620_databus: inout std_logic_vector(7 downto 0);
ad6620_add: out std_logic_vector(2 downto 0);
ad6620_wr: out std_logic;
ad6620_rd: out std_logic;
ad6620_cs: out std_logic
);
end interface;
architecture rtl of interface is
signal latch_address: std_logic_vector(7 downto 0);
begin
process (ale)
begin
if ale'event and ale='0' then
latch_address<=mcu_ad;---latch address
end if;
end process;
process (latch_address)
begin
if latch_address(7)='1' then
ad6620_cs <= '0';
ad6620_add<=latch_address( 2 downto 0);
else
ad6620cs<='1';
ad6620ka<="000";
end if;
end process;
ad6620_databus<=mcu_ad when (mcu_wr ='0') and
(latch_address(7)='1') else "ZZZZZZZZ";
mcu_ad<=ad6620_databus when (mcu_rd='0') and
(latch_address(7)='1' ) else "ZZZZZZZZ";
ad6620_rd<=mcu_rd;
ad6620_wr<=mcu_wr;
end rtl;
Article: 49603> > I agree. So try a fast synchronous FIFO. > Yes, but the point is that I _have_ to handle an incoming clock of unknow frequency (up to 75MHz). Or is there any other technique that can be applied? > If the boss wants a benchmark, do it in both Handel-C and > in an HDL. I guess that's what I'm going to do then... Another question regarding SRAMs in Celoxica (using the built-in SRAM access functions): I neither see a way of using ZBT or pipelined SRAMs without dividing the Handel-C clock down nor to make use of address and data pipelining of those RAMs. Further, I don't see how to create my own controller without dividing the Handel-C clock down by 2 to gain control of the data on the negative edge of the clock (I have to write the control signals at the falling edge and read data at the rising edge, yes?). Thanks, Bernhard M鋎erArticle: 49604
Flora Cathy wrote: > Heya, > > For the XC4000, It is said that any CLB can implement up to 9-input > function > This is possible since > 1- each FMAP can implement any 4-input Logic function > 2- HMAP can implement any 3-input Logic function > > Thus by combining 2FMAPs and HMAP, up to 4+4+1=9 input function can be > delivred.i.e.ResFunc=3_func(4_func(a,b,c,d),4_func(e,f,g,h),I) > > But if a user has a 9-input function to implement, he really needs to > identify what 4_func(a,b,c,d) , 4_func(e,f,g,h) and then 3_func to > use.... > > Although i see it feasible, surely not straighforward ? That is why it says "up to" 9-input function. It cannot implement every arbitrary 9-input function. > Now about the Virtex, it is said that each CLB can implement up to > 19-input function. > i Believe that this number has been deduced from 4+4+4+4(The 4 > LUTs)+2(F5)+1(F6) > > but i don't think that this will be for any logical function, simply > because F5,F6 are multiplexers and not 3-input function generator as > Xc4000 HMAP Same here. -- My real email is akamail.com@dclark (or something like that).Article: 49605
If there are generations it is 1 XC2000 2 XC3000 3 XC4000 4 Virtex 5 V2 6 V2Pro The 2K was a first attempt. The 3K family was really and improvement in routing and logic resources. The 4K added a ton of routing and hard wired adders, Distributed ram better clock trees, better I/O.... The Virtex took a whole new turn. Block rams, DLLs synthesis friendly lookup tables... The 5K 6K and 8K never really made it although the 5K is still around. The 5K was a cheap 4K for a while till the Spartans came out. The Spartans are not a family in their own right. Steve "Anonymous4" <nicemanYep@yahoo.co.uk> wrote in message news:f9028e31.0211161538.3f4abfd7@posting.google.com... > hi :-), > > I read that the Virtex family constitutes the 4th Xilinx FPGA > generation. > My first guess is that: > 1- The 1st generation comprises Xc2k,Xc3k and (Xc5k?). > 2- The 2nd generation consists on the Xc4k. > 3- The 3rd generation consists on the Xc6k (fine grain architecture ) > 4- The 4th generation consists on the Virtex family (owing SoC > implementation) > > Can anyone please highlight what was the " jump on the built-in > features" between two successive generations ? > can really the Xc5k be considered among the 1st category members? > where Spartan family position lies on? > can we consider the Virtex-Pro the 5th generation? > > thanks ;-)Article: 49606
Bernhard M鋎er wrote:
>>I agree. So try a fast synchronous FIFO.
> Yes, but the point is that I _have_ to handle an incoming clock of unknow
> frequency (up to 75MHz). Or is there any other technique that can be
> applied?
Synchronize signals for the slow domain as inputs with two D flops on
the system clock (120MHz).
>>If the boss wants a benchmark, do it in both Handel-C and
>>in an HDL.
>
> I guess that's what I'm going to do then...
Best to let the boss "discover" the right answer himself.
> Another question regarding SRAMs in Celoxica (using the built-in SRAM access
> functions): I neither see a way of using ZBT or pipelined SRAMs without
> dividing the Handel-C clock down nor to make use of address and data
> pipelining of those RAMs.
There is only one clock for synthesis. If 120 won't do it,
double it on-chip to 240 MHz. You will have to
do your own access procedures.
Handel-C is used for system-level simulations with
cpu and logic modules or for converting working C code
processes directly into hardware.
Since you are designing a new low-level hardware
function for synthesis, and there is no such existing code,
Handel-C may be a tough fit.
> Further, I don't see how to create my own controller without dividing the
> Handel-C clock down by 2 to gain control of the data on the negative edge of
> the clock (I have to write the control signals at the falling edge and read
> data at the rising edge, yes?).
No. If you need two edges, the clock is not fast enough
or the data is not wide enough.
-- Mike Treseler
Article: 49607hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>... > >I am not familiar with the techXclusive, can you provide a URL? > > http://support.xilinx.com/support/techxclusives/metas-techX32.htm Good article. Unfortunately, it doesn't mention the temperature conditions for the mesurements. Recently we suffered a problem which I attribute to metastability. Our design fed Intel 386EX processor with asynchronous READY# signal. Simetimes it caused the hang up. The processor's RD# signal was indicating that READY# is accepted while correspondent CS# signal remained asserted, indicating that READY# was missed. Looks like classic metastability problem, doesn't it ?! The problem was very temperature dependent. I never did a statistical mesurements (was to busy to understand and resolve the problem), but there was at least order of magnitude difference between 0 and -20deg Celsius (the colder is worse). Theoretically, the strong temperature dependance is expectable. It would be fine if Xilix will provide us with temperature data.Article: 49608
ted schrieb: > At a recent Xilinx seminar one of the presenters showed a slide describing > PicoBlaze and CoolBlaze simple 8 bit cores for Xilinx products. > > Looking at the XIlinx site, I only find a mention about Picoblaze, no mention > at all about CoolBlaze. > > Google produced no results whatsoever. > > Is Coolblaze a real product? If not why was it shown on the slides? > > PS we have a need for such a product, hence the asking! > > theo If also heard about the Coolblaze Microprocessor Core of Xilinx at a seminar. This is a future product and will be an 8 bit processor for the Coolrunner CPLD, but there was not announced a date of going public of this Core. ChristophArticle: 49609
Thanks guys. The QuartusII static timing analyzer shows that the timing for the clock on board is met. Also the RS 232 code and ports seem to work properly. I will check for any asynchronous code in the design and make that synchronous if present. Thanks, Prashant "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<ar3sm1$f84h1$1@ID-84877.news.dfncis.de>... > "Prashant" <prashantj@usa.net> schrieb im Newsbeitrag > news:ea62e09.0211151314.37041ecb@posting.google.com... > > Hi all, > > > > I'm using an FPGA board with an APEX20K1500E on it. My design produces > > 60,000 output values whch are stored in an external to FPGA on-board > > RAM. Then these values are read out onto the PC using the serial port. > > The production of the 64000 values is a repetitive process. > > > > When the data has been read onto the PC, I find one of the 60,000 > > values to be incorrect. But the index of the incorrect value changes > > everytime I rerun the code on the board. for e.g. in one run the > > 32,010th value could be wrong and the next run could have the 1,784th > > value could be wrong. > > A lot of things can go wrong. Is the design fast enough to reach your > clocking spped? Timing analyzer. > Is it a clean synchronous design? > On the connection to the external (SD)RAM, there might be signal integrity > issues. Ringing, Ground Bounce?? > Is the error introduced on the way to the PC via RS232?? > Run you RS232-FPGA connection in a endless loop and feed it with a PRBS > sequence, preferably a long one (2^15-1 or bigger) > Compare the incomming bitsequence with the expected (calculated) values. If > this runs fine, extend your data-loop to other regions of the circuit (data > handling etc.) until everything (also the RAM) is inside the data-loop.Article: 49610
Christoph Hauzeneder wrote: > > ted schrieb: > > At a recent Xilinx seminar one of the presenters showed a slide describing > > PicoBlaze and CoolBlaze simple 8 bit cores for Xilinx products. > > > > Looking at the XIlinx site, I only find a mention about Picoblaze, no mention > > at all about CoolBlaze. > > > > Google produced no results whatsoever. > > > > Is Coolblaze a real product? If not why was it shown on the slides? > > > > PS we have a need for such a product, hence the asking! > > > > theo > > If also heard about the Coolblaze Microprocessor Core of Xilinx at a > seminar. This is a future product and will be an 8 bit processor for the > Coolrunner CPLD, but there was not announced a date of going public of > this Core. An 8 bit core in a CPLD without any RAM ? makes little sense, unless they chase the 'Worlds most expensive multi-chip 8 bit uC' prize :) Suggests maybe they have a new Coolrunner comming, something like Lattices newest XPLD ? ( which does have RAM on-chip with CPLD ) I did see a uC core offering for the ProASIC (http://www.quickcores.com/) that looks to have educational potential, if not commercial. -jgArticle: 49611
This question is likely very trivial, but I haven't found the answer in any FAQ. I'm developing a ISE project for a Spartan II device; when I simulate it with ModelSim (I use the post-place&route model) the values stored in block RAM during the simulation aren't retained, and if I read back the same locations I apparently just get the initialization values. Is this correct? I hope it's just my mistake. :) -- LorenzoArticle: 49612
ModelSim support Block RAM simulation, I just use it now. Check you write enble signal if the data write into block ram really. "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> 写入消息新闻 :1NVB9.43841$8E3.1278377@twister2.libero.it... > This question is likely very trivial, but I haven't found the answer in > any FAQ. I'm developing a ISE project for a Spartan II device; when I > simulate it with ModelSim (I use the post-place&route model) the values > stored in block RAM during the simulation aren't retained, and if I read > back the same locations I apparently just get the initialization values. > > Is this correct? I hope it's just my mistake. :) > > -- > Lorenzo > >Article: 49613
already5chosen@yahoo.com (Michael S) wrote: >hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>... >> >I am not familiar with the techXclusive, can you provide a URL? >> >> http://support.xilinx.com/support/techxclusives/metas-techX32.htm > >Good article. Unfortunately, it doesn't mention the temperature >conditions for the mesurements. > >Recently we suffered a problem which I attribute to metastability. Our >design fed Intel 386EX processor with asynchronous READY# signal. >Simetimes it caused the hang up. The processor's RD# signal was >indicating that READY# is accepted while correspondent CS# signal >remained asserted, indicating that READY# was missed. Looks like >classic metastability problem, doesn't it ?! I would attribute it to a duff design - the 386EX datasheets specify a setup and hold time for the READY# input. The datasheets do not specify what happens if READY# is not stable during that period. You experience shows the processor can get screwed up pretty badly - but it is still your fault. The 'problem' inside the 386 is almost certainly a race and not metastability. I do wish chip manufacturers would be a bit more specific about which violation of timing specifications can really screw up their parts.Article: 49614
On Sun, 17 Nov 2002 19:21:42 GMT, Steve Casselman <sc@vcc.com> wrote:
>
>1 XC2000
>2 XC3000
>3 XC4000
>4 Virtex
>5 V2
>6 V2Pro
>
>The 5K was a cheap 4K for a while till the Spartans came out. The Spartans
>are not a family in their own right.
Nor is the V2Pro. It's a lateral move from the V2,
kind of like the move from Virtex to Virtex-E
(although even less of an improvement, IMHO, since
the V-E at least included a speed bump).
At the moment, the lowest price per LUT is the XC2S300E.
I look forward to a Spartan-3 that beats it. But I guess
Xilinx should release a real next-generation (beyond
V2/V2Pro) product first.
OTOH, maybe Moore's law is ending early; I have it pegged
for 2005. But if Xilinx can't follow the V2 with anything,
just add features around the edges to try to fool us into
_thinking_ chips are fullowing the curve, that would be
the beginning of the end.
- Larry
Article: 49615In article <slrnatgmrb.nsd.ldoolitt@recycle.lbl.gov>, Larry Doolittle <ldoolitt@recycle.lbl.gov> wrote: >OTOH, maybe Moore's law is ending early; I have it pegged >for 2005. But if Xilinx can't follow the V2 with anything, >just add features around the edges to try to fool us into >_thinking_ chips are fullowing the curve, that would be >the beginning of the end. Actually, the stuff on the periphery IS a really big deal, as now we have ways of feeding data at something approaching the FPGAs computational rate. There is a LOT of processing power in 10,000+ 200 MHz+ LUTs. The other observation is that one really can't make the carry chain, luts, or interconnect any faster using architectural tricks (eg, what the processor people HAVE done), unless one is willing to add retiming into the toolflow and therefore increase the pipelining considerably. Without that, the FPGA world is somewhat limited to process shrink related performance and AREA. FPGAs are nice in that the throughput does scale effectively linearly with area, and they still have that going with the continual process shrinking. So as long as the fab people keep shrinking, the FPGA performances will keep improving. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 49616
Michael S wrote: > > hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>... > > >I am not familiar with the techXclusive, can you provide a URL? > > > > http://support.xilinx.com/support/techxclusives/metas-techX32.htm > > Good article. Unfortunately, it doesn't mention the temperature > conditions for the mesurements. > > Recently we suffered a problem which I attribute to metastability. Our > design fed Intel 386EX processor with asynchronous READY# signal. > Simetimes it caused the hang up. The processor's RD# signal was > indicating that READY# is accepted while correspondent CS# signal > remained asserted, indicating that READY# was missed. Looks like > classic metastability problem, doesn't it ?! > The problem was very temperature dependent. I never did a statistical > mesurements (was to busy to understand and resolve the problem), but > there was at least order of magnitude difference between 0 and -20deg > Celsius (the colder is worse). > Theoretically, the strong temperature dependance is expectable. It > would be fine if Xilix will provide us with temperature data. I am surprised that it got worse with temperature. Silicon delays are less at colder temps, which in turn allows more time for metastability resolution within any path that has a significant delay. Since you saw more frequent failures, this either might not have been metastability or if the metastable FF fed a path that had little delay and was mostly slack time, the increased incidence may have been due to the gain bandwidth being reduced at lower temps. I don't know enough about FFs to know how this is affected by temperature. But I am not clear as to what you think the metastable path is. If it is the Ready signal being presented to the 386, then the problem would be inside the 386. So why would you be looking to Xilinx for info? In general, I would expect the effect of temperature to be small in relation to the exponential effect of slack time. If you see a metastable failure at *any* temperature, it is because not enough time was provided for settling. -- 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: 49617
> Buy, beg, borrow or steal (well, no don't steal) a copy of P.P.
Vaidyanathan's multirate filtering
> book (You can buy it through the bookstore on my website, which will give
me a kickback which in
> turn helps to support the website).
Don't suppose you give student discounts ('specially students from countries
with a 3rd world currency) ????? :)
adrian
Article: 49618>I am surprised that it got worse with temperature. Silicon delays are >less at colder temps, which in turn allows more time for metastability >resolution within any path that has a significant delay. Since you saw >more frequent failures, this either might not have been metastability or >if the metastable FF fed a path that had little delay and was mostly >slack time, the increased incidence may have been due to the gain >bandwidth being reduced at lower temps. I don't know enough about FFs >to know how this is affected by temperature. > >But I am not clear as to what you think the metastable path is. If it >is the Ready signal being presented to the 386, then the problem would >be inside the 386. So why would you be looking to Xilinx for info? I could easily imaging that the sort of delay changes seen with temperature would be just the right thing to tickle problems due to either setup/hold violations or metastability. Suppose the problem is a simple setup problem - it takes x ns to setup FF X, and y ns for the same signal to get setup for FF Y. Anything between x and y will cause troubles. Just adjust temperature to hit that window. Similarly, if you only have one FF, and the setup time is z, then you will get no metastability problems if you meet z, and you will get a lot of them if you are a little under z. (I'm talking measured setup times for this particular device/conditions, not data sheet times.) Temperature changes on one device (cold spray) could easily change the actual setup time for another device while the setup time it needs doesn't change much because its temperature doesn't change much. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 49619
hamish@cloud.net.au writes: > Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: > > Has Xilinx said anything about future versions of WebPack being able > > to support the 2VP4? It seems a shame that it doesn't support at > > least one part that actually contains a PowerPC processor. The number > > Why wouldn't you buy the tools if using such a high-end part? The PowerPC model is a SWIFT model, which requires a SWIFT compatible simulator. As far as I know the object files for this model is only available for SPARC/Solaris (correct me if I'm wrong). This means that you will have to get a expensive simulator as well as a expensive machine to be able to run your simulation. The cost of the full ISE license from Xilinx will be peanuts... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petterArticle: 49620
Dear all, I would like to understand XC5204 bitstream format and be able to design a program that takes bitstream (*.bit) file as input and gives *.ncd file (place and route result file) or structural VHDL code file as output ... I know that it has been made succesfuly by NeoCAd before and some fans are working around with Virtex family .... Actually, I found a lot of useful information in the XC5200 datasheet from Xilinx .. but something that I don't understand is the following ... "Bits per Frame = (34 x number of Rows) + 28 for the top + 28 for the bottom + 4 splitter bits + 8 start bits + 4 error check bits + 4 fill bits + 24 extended write bits = (34 x number of Rows) + 100" is the part that I don't understand ... I can see more than 4 splitter bits ... Actually, I see 8 bits and divided on two bytes .. something like that FC 7F so, C& are the splitter .. they are exactly at the mid of the frame .... sometimes , I see something like 04 also divided on two bytes ... But I never found the splitting bits constant ... their values depend onm the frame position and contents .... Another remark ... How does Xilinx calculate the checksum bits ... I figured out that the checksum of two identical frames is not the same ... Also, if i have changed something in the ncd file , the checksum values of so many frames are changed ... sometimes, i see the checksum changes before the frame of the data changes .. !!!!! The last comic is , what are the 28 bits for the top and the 28 bits for the bottom .. ??? what does it mean ... ???? Could anyone help with these things .. ??? With regards Mohamed ShihaArticle: 49621
Nicholas C. Weaver > Without that, the FPGA world is somewhat limited to process shrink > related performance and AREA. FPGAs are nice in that the throughput > does scale effectively linearly with area, and they still have that > going with the continual process shrinking. So as long as the fab > people keep shrinking, the FPGA performances will keep improving. Lots of good points to be argued with. But don't underestimate the effect of ever-increasing on-chip memory levels and memory speeds. In this case, more is different. For some problems, more is revolutionary.Article: 49622
Hi all Anyone know a sinple way to program a max3000 ?? regard -- ********************************************************************** * Per favore non mandatemi allegati in Word o PowerPoint * **********************************************************************Article: 49623
When using nested for-generate statements (VHDL) in XST synthesis tool from Xilinx, is it possible to make XST name instances like this: name_xx_yy instead of like this: namexxyy? (x is the outermost generate-variable and y is the innermost generate-variable.) The problemn with the current XST method is that it gets confusing when the generate variables gets bigger than 10. How to differ between instance 1,10 and 11,0 ? Now, XST just adds a zero at the end if the instance name has been used before, but that makes it difficult to make automatic scripts that must know the instancenames that gets generated. Asbj鴕nArticle: 49624
Hello,
I tried to do something in jbits, but my problem is, I dont know how
to use DLLs (in verilog and VHDL exist macros for using them) with
jbits (2.8). I already grepped through the complete documentation, and
all I got was the a function, that describes me, if a a tile is a
DLL-tile or nor. Maybe someone here know, how to do this, or can at
least say, that it isnt possible.
Florian
--
int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u)
["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&&
I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
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