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
Hear, Hear! I'm biased towards Xilinx not because of any allegiance or ties to the company, but because it is the best silicon for the applications I deal with. I'd love to see more postings by those who find other architectures more suitable for their applications. Perhaps the lack of other proponents is indicative of the ability of the other architectures ;-O "S. Ramirez" wrote: > > Yoram, > This is a side note to your question. Earlier, someone claimed that > this newsgroup is dominated by Xilinx. Since it is an FPGA newsgroup, I > would like to see Altera, Actel, Lucent, Quicklogic, Atmel, Lattice and > others post what they have to answer Yoram's question. There is nothing > stopping these vendors from posting various messages explaining what they > have or answering questions and offering clarification. And there is > nothing stopping engineers from posting problems and questions related to > these other vendors. > Please post and add more information wealth to this newsgroup. > -Simon Ramirez, Consultant > Synchronous Design, Inc. > > <yorams70@my-deja.com> wrote in message news:8o3ld7$185$1@nnrp1.deja.com... > > Hi. > > I would like to know what is the largest fpga in the industry in > > terms of internal RAM. (and I mean RAM that it's usage will not > > come on the cost of logic cells use). > > > > ThankX, > > Yoram. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25051
"S. Ramirez" wrote: > Yoram, > This is a side note to your question. Earlier, someone claimed that > this newsgroup is dominated by Xilinx. Since it is an FPGA newsgroup, I > would like to see Altera, Actel, Lucent, Quicklogic, Atmel, Lattice and > others post what they have to answer Yoram's question. There is nothing > stopping these vendors from posting various messages explaining what they > have or answering questions and offering clarification. Well, Altera has a little self-inflicted problem. They claim that even their big parts are not FPGAs, but rather CPLDs. My theory is that they therefore think they need to ignore us here. I agree that the newsgroup would be better off with a free exchange of ideas and comments. As long as we avoid breast-beating and advertising... PeterArticle: 25052
Steve Oldridge wrote: > I think the real problem you're gonna face is processing those 200 bits... Routing > those 200 lines from the block Rams to the CLBs for processing is going to be no > mean feat. It's not so bad. each BlockRAM has a "vertical" height of 4 CLBs, so the 13 BlockRAMs have a height of 52 CLBs, of course normally, (in XCV300E or smaller), broken down into two banks. Anyhow, there is (nowadays) enough routing for the data. "This is not your father's XC4025 anymore..." Peter Alfke, Xilinx ApplicationsArticle: 25053
In article <39A5A6CE.F3529E88@xilinx.com>, Peter Alfke <peter.alfke@xilinx.com> wrote: >"This is not your father's XC4025 anymore..." 4025? Bah, such a huge waste of silicon. Back when I was an undergraduate, we had 4003s and we LIKED them. (We didn't like the 1+ hour compile times, however. :) -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 25054
That shouldn't be a problem. There's plenty of routing to get in and out of them pretty efficiently, and with a little care you can even do it faster than most people think "real designs" can be clocked. Steve Oldridge wrote: > > I think the real problem you're gonna face is processing those 200 bits... Routing > those 200 lines from the block Rams to the CLBs for processing is going to be no > mean feat. What are you doing that you need all 200 bits at once? That said, I > can't really think of a way around the problem unless you can do with accessing the > data in chunks (in which case you don't really need a 200 bit wide RAM in the first > place). Just something to consider... > Steve > > > Gerhard Griessnig wrote: > > > > > > I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool. > > > > > > My problem is that my RAM has a width of 200 bits. > > > > > > Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a > > > complex addressing. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25055
> [1] "Metastability Report for FPGAs," Quicklogic Data
> Book, 1994, pp. 523-526.
^^^^
> [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
^^^^
Ugh. Maybe it's a conspiracy to make Xilinx look good. :)
--
These are my opinions, not necessarily my employers. I hate spam.
Article: 25056rickman <spamgoeshere4@yahoo.com> writes: > [...] > A completed application, > > A "consumer report" (otherwise known as a credit check) authorization, > > A Background questionnaire release form, > > Then they want me to leave behind a urine sample for drug testing. > [...] It ain't gonna be too long until you'll have to go through genetic screening to get the job. A brave, new world, it is ... Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 25057
Hal Murray wrote: > > [1] "Metastability Report for FPGAs," Quicklogic Data > > Book, 1994, pp. 523-526. > ^^^^ > > > [2] Actel Data Book, 1992, pp. 5-1 to 5-2. > ^^^^ > > Ugh. Maybe it's a conspiracy to make Xilinx look good. :) While I am almost alway a believer in conspiracy theories, I can't say that I know of one here. I just had some old books laying around the study. Now, I don't recall any of the newer books having any more update to date information. Perhaps Dan or John can chime in. I did try and hunt for more information on various www sites to update things but couldn't find anything relevant. Help, anyone? Have a nice evening, rkArticle: 25058
"Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:39A5A2AB.2D5797B0@xilinx.com... > It's around 25 mm square, or an inch for you non-metric folks. > > Bragging about large chip size always gives me a creepy feeling. > Here we have a bunch of engineers and layout designers who sacrificed their > lunch, their sleep, and their family life to squeeze the design as small as > they possibly could do it. > And then somebody brags about how BIG the chip is. :-( > I wish it were smaller, then it would be both faster and cheaper. But this > size was the smallest we could make it, of course only until we shrink it > next year.... > But, hats off to the fab ( in Taiwan ) who can produce such monster chips > without any defect, and to the guys who can stuff it into a package and bond > more than a thousand wires.. > > Isn't it almost a miracle ? > Peter Alfke They said the same thing about the 22V10 (except for the die-size of course)! -Simon Ramirez, Consultant Synchronous Design, Inc.Article: 25059
"S. Ramirez" wrote: > > It's around 25 mm square, or an inch for you non-metric folks. > > Bragging about large chip size always gives me a creepy feeling. > > Here we have a bunch of engineers and layout designers who sacrificed their > > lunch, their sleep, and their family life to squeeze the design as small as > > they possibly could do it. > > And then somebody brags about how BIG the chip is. :-( But the real question is what is the best cost / performance ratio. Big chips cost TOO much. Small chips do TOO little. Plus the price of Sockets (What you want fix a computer board by replacing a defective chip - ha ha ha !) and the PCB complexity and clock speed all are factors. Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 25060
on 8/6/00, Jan Gray wrote:
>I am working on optimized processor cores for Virtex
>and I have a strange result, perhaps a bug in the tools.
>This problem is with F2.1i SP6.
<snip description of latch/write clock polarity problems>
I hadn't used Virtex/Spartan-II CLB latches before;
after experimenting with them for a while, I'd say it's
definitely a bug.
Problem Summary:
The problem occurs in both 3.1i SP2 and 2.1i SP6.
MAP and PAR have their clock polarity packing rules
backwards: when packing latches with clocked memory
elements, they reject the valid combinations and
allow the invalid ones.
In the resulting hardware, the latches have the
polarity that was specified, but the clock sense of
the RAM or SRL16 elements is inverted. ( Verified
both by simulation and in hardware using a XC2S100 ).
More Info:
ftp://members.aol.com/fpgastuff/
latch_bug1.txt more info on problem and test cases
latch_bug1.zip:
latch_bug1.txt
ram_test\ design using RAM's
srl_test\ design using SRL16's
Brian Davis
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25061Hi, everyone. I've received my copy of the Xilinx 3.1i software, and installed it this morning. It seems to me that it doesn't support multiple entities in a single file! I just want to check to see if anyone's run into the same thing. This is what I did: 1. Installed it. 2. Created new project (Since it doesn't seem to read 2.1i projects) 3. Added all my source files from an old project. this includes "Ram.vhd", which has a bunch'o'entities for different RAM constructs. 4. Looked at the "Modules" window, where I found only the last entity in any given file was displayed. Any ideas, anyone? -KentArticle: 25062
Ot further my explanation a bit more: When I add the files, I'm given an option to add the file as a VHDL module, or as a Package. Perhaps I can have only one entity per module file, and if what I really want is a collection of entities, like RAM structures, then maybe it should be a Package? -Kent korthner@hotmail.nospam.com (K. Orthner) wrote in <8F9B82AFEkorthnerhotmailcom@158.202.232.7>: >Hi, everyone. > >I've received my copy of the Xilinx 3.1i software, and installed it this >morning. > >It seems to me that it doesn't support multiple entities in a single >file! > >I just want to check to see if anyone's run into the same thing. This >is what I did: > >1. Installed it. >2. Created new project (Since it doesn't seem to read 2.1i projects) >3. Added all my source files from an old project. this includes >"Ram.vhd", which has a bunch'o'entities for different RAM constructs. >4. Looked at the "Modules" window, where I found only the last entity in >any given file was displayed. > >Any ideas, anyone? > >-KentArticle: 25063
I am told that referring to the the Xilinx BlockRAM as RAMB4 is a clue that a higher density embedded RAM (RAMB8?) may be on the way. But if I knew anything ... Peter Alfke wrote in message <39A58E60.5054A94B@xilinx.com>... >Let me describe the biggest FPGA that Xilinx is shipping now ( and I mean shipping >today to paying customers ): > >The Virtex XCV3200E has a 104 x 156 array of CLBs. That makes it 16,224 CLBs, each >with four Logic Cells. That means there are 64,896 Logic Cells, each consisting of >a 4-input look-up table plus a flip-flop. >You can use each LUT as either logic (ROM), as 16-bit RAM, or as 16-bit shift >register. ( Altera can use the LUT only as logic (ROM). > >Independent of these CLBs, there are 208 BlockRAMs, each with 4096 bits and two >completely independent access mechanisms ( true dual-ported). That makes it >851,968 bits of RAM, not counting the RAMs in the LUTs. > snipArticle: 25064
This is a multi-part message in MIME format. --------------1809166CFA9E31CE13276557 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, The DLL's on Virtex and VirtexE have the three properties - DUTY_CYCLE_CORRECTION - CLKDV_DIVIDE - STARTUP_WAIT. There is no problem for simulation in VHDL of the units unisim.CLKDLL or unisim.CLKDLLHF; the properties are defined here by means of generics. Questions: 1. How get the properties defined for implementation? 2. Can this be done in the VHDL source code? 3. Or is this done with the Design Manager? Thanks for your immediate help, best regards Markus --------------1809166CFA9E31CE13276557 Content-Type: text/x-vcard; charset=us-ascii; name="mmichel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Markus Michel Content-Disposition: attachment; filename="mmichel.vcf" begin:vcard n:Michel;Markus tel;fax:+41 (0)61 336 22 00 tel;work:+41 (0)61 336 22 22 x-mozilla-html:FALSE org:Kontron Medical AG version:2.1 email;internet:mmichel@kontronmedical.ch title:dipl. El'Ing. ETH adr;quoted-printable:;;Reinacherstr. 131=0D=0AP.O. Box;CH- 4002 Basel;;;Switzerland x-mozilla-cpt:;5808 fn:Markus Michel end:vcard --------------1809166CFA9E31CE13276557--Article: 25065
<brian_m_davis@my-deja.com> wrote in message news:8o4ng2$8rs$1@nnrp1.deja.com... > on 8/6/00, Jan Gray wrote: > > >I am working on optimized processor cores for Virtex > >and I have a strange result, perhaps a bug in the tools. > >This problem is with F2.1i SP6. > > <snip description of latch/write clock polarity problems> > > I hadn't used Virtex/Spartan-II CLB latches before; > after experimenting with them for a while, I'd say it's > definitely a bug. > > Problem Summary: > > The problem occurs in both 3.1i SP2 and 2.1i SP6. > > MAP and PAR have their clock polarity packing rules > backwards: when packing latches with clocked memory > elements, they reject the valid combinations and > allow the invalid ones. > > In the resulting hardware, the latches have the > polarity that was specified, but the clock sense of > the RAM or SRL16 elements is inverted. ( Verified > both by simulation and in hardware using a XC2S100 ). My thanks to Brian for picking up the ball and running with this, and verifying in several ways that map/par are wrong here. It is astonishing that this problem was not found, reported, and fixed by 3.1i, but I suppose no one is using RAM near latches. This is a "good thing" -- I wouldn't do so either except this was a last-ditch effort to avoid wasting area in my designs. Brian's legwork confirms there is no way to do what I was hoping to do. I went down this path because in XC4000s I made compact, read/write per clock register files using single-port select RAM, driving a write address and clocking the write on the rising edge, then driving a read address and capturing read data in the same CLBs' flip-flops on the falling edge. Alas in Virtex the slice architecture does not permit the flip-flop clock to be inverted with respect to the RAM clock. So I had tried to use positive enabled latches instead, and the tools erroneously let me do so, but now Brian confirms that the only configuration the hardware supports has the latch closed when I need it to be open and vice versa. Workarounds: I could... * clock the reg file twice as fast, perhaps via a separate 2X clock from a DLL, but this constrains the min cycle time of the register file, hence the pipeline, to be twice the min cycle time of the select RAMs, e.g. 2xTwc = ~12 ns in S2-5 = ~ 80 MHz, not fast enough. * move the register file output register flops (that are clocked on the clock falling edge) to other CLBs (and invert the clock to those FFs), but this use of local interconnect is slower, and this structure makes floorplanning more awkward. * use dual-port RAMs, but these are half as area efficient at best. (Sometimes worse -- for n x 32 reg files from 16x1 dprams, I also need output muxes (but perhaps F6MUXs work).) * use dual-port block RAMs, but these are slower and are spoken for. So I am using dual-port RAMs, and have filed this next to "PAR won't do H-muxes" in the "missed opportunities to save area" file. Jan Gray Gray Research LLCArticle: 25066
I am not disclosing the name of the companies I have dealt with for several reasons. 1) I don't feel this adds anything to the discussion. If I tell you it was IBM (it wasn't) how does that add to any of the points being discussed? I can give you all the details of the incident without telling you the name of the company. 2) I don't want to violate any agreement that they feel was implied, even though I did not sign. Actually I did sign with an addendum requiring a written indication of the sensitive information which was not to be revealed. Since they did not provide any information to me on what was sensitive, I don't feel any of the conversations was sensitive, but they might. 3) I do have a very low level of fear that I will feel repercussions of several forms. The company named may sue me. Other people may have less respect for me (as I could be considered a snitch). Other companies may view me as a trouble maker (the same snitch thing). 4) I don't feel the need to warn anyone of a company pushing a paper in front of you to sign. Each of us should be able to recognize this happening at the time it happens. It is then up to them to do what they feel is right. It is not my place to tell them what is "correct". Can you explain in clear concise language why you feel a company name is important to this conversation? Which many have stopped reading, BTW... guess why! Neil Nelson wrote: > You ask me why I wanted names. I can go with (A) and (B) and the > several other reasons I have been giving. But however confusing > I am, it is not that confusing that no one has given an argument > as to why they are not giving the names of the companies they > say are not behaving appropriately. I.e., you may wish me to > explain my reason for asking and say that it is confusing, but > still no names have been given and no reason has been given for > not giving names. The original topic was one that dealt with not > disclosing. Why are we not disclosing names? Which it would seem > we must know if we say there is in fact a company behaving poorly? > > Regards, > > Neil Nelson > -- 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: 25067
Hal Murray wrote:
>
> > Please, Altera and Xilinx, never give up the command line interface to
> > your tools.
>
> I'd like to second that. Good documentation is important too.
>
> What I really want is something that cooperates with make.
> Aside from all the options that I can specify on the command
> line, I need to understand the sequence of steps to go through
> and I need to know what files each step produces.
>
> I consider the Makefile to be a critical part of the documentation.
For larger designs "make" does not fit very well, unless you build
wrappers around the tools. It is very design specific what is
considered a severe problem (with the consequence, make should stop)
and what is ok. Just yesterday someone complaint that certain IOs
were not put into the IOBs. Hence, the number of "IOB FFs" reported
by make is crucial for this design. The same number will be irrelevant
for
other designs.
What I loved to have is a more detailed control over the individual
actions performed.
In the same style synopsys dc_shell lets you perform individual steps.
This would allow to apply different optimization styles and
optimization goals for design parts, e.g. in map.
Or imagine a floorplanner where you could perform all those
steps by a script. The situation has been improved, see for instance
fpga editor.
But I still miss a lot of output stuff there.
Something like:
sort routed nets by selection,
print the top 20 lines. to a file
call a perl script
include script xyz
or par with something like:
select all nets which match a given pattern.
deselct those where not all pins are placed.
Route the remaining.
mark these routed nets "dont touch"
and so forth.
If the million gates barrier is crossed, such advanced methods are
needed.
And when I am already dreaming:
I would like to have larger hard macros,
they were limited by the number of nets.
(or did that improve in 3.1i)
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee 160
D-23538 Luebeck Germany
Tel.: +49 451 500-3741, Fax: -3687
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 25068Jan Gray wrote: > However, in this case, it is neither obvious, nor documented, whether the > slice latches are open when clk is high or when clk is low (independent of > whether said clock is inverted). > I wonder how much sleep the FPGA device engineers lose at night from reading how pushed to the limit his designs are. If he ever decided to form his own company and build FPGA's his would be a very hot product. Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 25069
Hello, I have a problem with the names Synopsys_1999.10 uses for multiple instances of a component created using the VHDL "generate" construct. For instance, when using a construct like for i in 0 to 7 generate instance_name: component_name port map ( ... ); end generate; eight instances of component_name would be created. Synopsys adds a suffix to the instance_names to get different names for all instances. Up to now I was used to this suffixes being sequential numbers (in most cases equal i), but since updating to Synopsys_1999.10 these numbers seem to have no relation to i but instead choosen according to some hidden rule known only by Synopsys. Does anyone out there know how to force Synopsys to use sequential numbers as suffixes or a VHDL construct to define instance names as a function of i? TIA JensArticle: 25070
Gerhard Griessnig wrote: I need a RAM with a deep of 480 (impossible with virtex V300 - so i use for my project the half :240) and a width of 200 bits for implementing a switch for a realtime LAN. The LAN is developed by us and has a special protokol which requiers 200 bits width packages. Is it possible to get all 200 bits into a 200 bit shift register in one Cycle (timing)? THANKS Gerhard Vhdlcode ? > I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool. > > My problem is that my RAM has a width of 200 bits. > > Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a complex addressing.Article: 25071
Ben,
First of all, I didn't write what's below. Peter Alfke of Xilinx wrote
that.
Second, your question "what is the best cost/performance ratio?" is a
good question, but there is still a fringe need for costly chips that do a
lot. I guarantee you that someone is going to use those chips. It may not
be their best seller, but it will sell and it will help drive Xilinx's
technology down the road to even bigger chips that cost less per gate. As
Peter said, die shrinks will ensure that this happens.
-Simon Ramirez, Consultant
Synchronous Design, Inc.
"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message
news:39A5D6FC.2D7D3286@jetnet.ab.ca...
> "S. Ramirez" wrote:
> > > It's around 25 mm square, or an inch for you non-metric folks.
> > > Bragging about large chip size always gives me a creepy feeling.
> > > Here we have a bunch of engineers and layout designers who sacrificed
their
> > > lunch, their sleep, and their family life to squeeze the design as
small as
> > > they possibly could do it.
> > > And then somebody brags about how BIG the chip is. :-(
>
> But the real question is what is the best cost / performance ratio.
> Big chips cost TOO much. Small chips do TOO little. Plus the price
> of Sockets (What you want fix a computer board by replacing a defective
> chip - ha ha ha !) and the PCB complexity and clock speed all are factors.
> Ben.
> --
> "We do not inherit our time on this planet from our parents...
> We borrow it from our children."
> "24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.html
>
Article: 25072Jan, For this type of inquiry, I use the FPGA editor to see if something will work in the architecture before I even start to code it. If you had done so, it would have become immediately obvious that the silicon doesn't support what you were trying to do. SImilarly, I think that if you look at it, you'll find the F5 and F6 mux controls are shared with the RAM write strobes, so there's a good shot you won't have access to them either. Basically, if you are using the RAM or SRL16 modes, the registers are only usable to register the RAM output on the same edge as the ram clock, and the S/R is not available. THe FF CE is still available. This is one of those things I miss fromthe 4K architecture. Perhaps the SRL16E can be useful to you. You can get pseudo 2 port access if the input is not random by shifting data in and then using the address lines to access the data randomly. Jan Gray wrote: > > <brian_m_davis@my-deja.com> wrote in message > news:8o4ng2$8rs$1@nnrp1.deja.com... > > on 8/6/00, Jan Gray wrote: > > > > >I am working on optimized processor cores for Virtex > > >and I have a strange result, perhaps a bug in the tools. > > >This problem is with F2.1i SP6. > > > > <snip description of latch/write clock polarity problems> > > > > I hadn't used Virtex/Spartan-II CLB latches before; > > after experimenting with them for a while, I'd say it's > > definitely a bug. > > > > Problem Summary: > > > > The problem occurs in both 3.1i SP2 and 2.1i SP6. > > > > MAP and PAR have their clock polarity packing rules > > backwards: when packing latches with clocked memory > > elements, they reject the valid combinations and > > allow the invalid ones. > > > > In the resulting hardware, the latches have the > > polarity that was specified, but the clock sense of > > the RAM or SRL16 elements is inverted. ( Verified > > both by simulation and in hardware using a XC2S100 ). > > My thanks to Brian for picking up the ball and running with this, and > verifying in several ways that map/par are wrong here. It is astonishing > that this problem was not found, reported, and fixed by 3.1i, but I suppose > no one is using RAM near latches. This is a "good thing" -- I wouldn't do > so either except this was a last-ditch effort to avoid wasting area in my > designs. > > Brian's legwork confirms there is no way to do what I was hoping to do. > > I went down this path because in XC4000s I made compact, read/write per > clock register files using single-port select RAM, driving a write address > and clocking the write on the rising edge, then driving a read address and > capturing read data in the same CLBs' flip-flops on the falling edge. Alas > in Virtex the slice architecture does not permit the flip-flop clock to be > inverted with respect to the RAM clock. So I had tried to use positive > enabled latches instead, and the tools erroneously let me do so, but now > Brian confirms that the only configuration the hardware supports has the > latch closed when I need it to be open and vice versa. > > Workarounds: I could... > > * clock the reg file twice as fast, perhaps via a separate 2X clock from a > DLL, but this constrains the min cycle time of the register file, hence the > pipeline, to be twice the min cycle time of the select RAMs, e.g. 2xTwc = > ~12 ns in S2-5 = ~ 80 MHz, not fast enough. > > * move the register file output register flops (that are clocked on the > clock falling edge) to other CLBs (and invert the clock to those FFs), but > this use of local interconnect is slower, and this structure makes > floorplanning more awkward. > > * use dual-port RAMs, but these are half as area efficient at best. > (Sometimes worse -- for n x 32 reg files from 16x1 dprams, I also need > output muxes (but perhaps F6MUXs work).) > > * use dual-port block RAMs, but these are slower and are spoken for. > > So I am using dual-port RAMs, and have filed this next to "PAR won't do > H-muxes" in the "missed opportunities to save area" file. > > Jan Gray > Gray Research LLC -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25073
Markus Michel wrote: > > Hello all, > > The DLL's on Virtex and VirtexE have the three properties > - DUTY_CYCLE_CORRECTION > - CLKDV_DIVIDE > - STARTUP_WAIT. > There is no problem for simulation in VHDL of the units > unisim.CLKDLL or unisim.CLKDLLHF; the properties are defined > here by means of generics. > > Questions: > 1. How get the properties defined for implementation? UCF file entries or attributes on the instances in the source > 2. Can this be done in the VHDL source code? Yes, if the synthesis passes user attributes through to the netlist. I believe xilinx has an appnote on-line concerning instantiation of DLLs and setting up the parameters. > 3. Or is this done with the Design Manager? > > Thanks for your immediate help, best regards > Markus -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25074
No, you won't get 200*480 in block RAM in a V300, but you might be able to use CLB RAM or SRL16's to make up the deficit. at 68 bits per CLB, this is quite reasonable. If you need speed, the best bet is to use the CLB RAM as a shift register buffer rather than random access, provided you can come up with a scheme that works for your design. You'd need about a third of the array (448 CLBs minimum) to make up the deficit. If your logic is not too intense, then you could probably make that work. If logic an memroy combined is too much, then you need to go to a bigger device...you can't shove 10 lbs of manure in a 5 lb sack. As to the getting all the bits into a shift register at once, sure you can. The shift register will take up 200 luts though. You don't mention what your clock cycle is. Often, you can use a multiplied clock to take better advantage of the architecture and thereby shrink the design. Gerhard Griessnig wrote: > > Gerhard Griessnig wrote: > > I need a RAM with a deep of 480 (impossible with virtex V300 - so i use for my project the half :240) and a width of 200 bits for implementing a switch for a realtime LAN. > The LAN is developed by us and has a special protokol which requiers 200 bits width packages. > > Is it possible to get all 200 bits into a 200 bit shift register in one Cycle (timing)? > > THANKS Gerhard > > Vhdlcode ? > > > I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool. > > > > My problem is that my RAM has a width of 200 bits. > > > > Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a complex addressing. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.com
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