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
Hi everybody, I know how to initialize instantiated ditributed ram or block ram (in VHDL). I don't know how to do this with inferred ram. Do YOU know?, have an code example? Many thanks Wolfgang -- __________________________________________________________ News suchen, lesen, schreiben mit http://newsgroups.web.deArticle: 44351
The package now generates synthesizable verilog file with Icarus verilog. And I add another test file (i8088 semi-compatible but not tested well). Feel free to download and use the package. See more: http://shimizu-lab.dt.u-tokai.ac.jp/indexe.html Regards, ---------------------------------->--------------------------->> Naohiko Shimizu Department of Communications Engineering, School of Information Technology and Electronics, Tokai University 1117 Kitakaname Hiratsuka 259-1292 Japan TEL.+81-463-58-1211(ext. 4084) FAX.+81-463-58-8320 http://shimizu-lab.dt.u-tokai.ac.jp/ <<--------------------------------<-----------------------------Article: 44352
I believe that different synthesis tools have different block ram inference capabilities, so I stick with the instantiation method. One may put a generic type of wrapper around the instantiated "entity" to make it more transportable across different vendors. Embedded block RAM is very fast compared to going off chip. If the memory requirements are modest, if you need RAM, one does not have to squander IO resources to connect to external RAM. Hope this helps, NewmanArticle: 44353
Stéphane, I do not know what an ATA bus is, so I can not answer. As long as the IO drivers do not pull up to greater than Vcco + 0.5V with current more than 10 mA, no resistor is required. A quick IBIS simulation of the ATA output into a capacitive load would show if this is true. Do you have the IBIS models for the ATA bus driver? Is there a website for them? The resistor is required if one is able to source current at greater than Vcco + 0.5V to the Virtex input diode clamp. Austin Stéphane Guyetant wrote: > Hi all, > > after reading virtex "5V tolerant I/Os" > (see http://www.xilinx.com/products/virtex/techtopic/vtt002.pdf ) > and Spartan II functional description, I would say that I can use a > Spartan-II > (PQ208 package) with all VccO=3.3V in LVTTL mode directly on a 5V ATA > bus > with no need of resistor or buffering. Right? > > Any comment/suggestion appreciated! > Thx, > StephaneArticle: 44354
Ted, What you are asking for is very old technology (anything > 5V is larger than 0.35u). I doubt it exists anymore. Austin ted_jmt@zapta.com wrote: > >> > >> 2. Must work on 5V (or higher) > > > >Interesting request - How much higher - and for what loads ? > > 10V will be optimal. Current requirements are very very low (250uA is > more than enough) > > > > >150 i/o is a lot in one package - what is this driving ? > >( are all the loads in one place ? ) > > > >Is the IO by Serial or parallel BUS, 8 or 16 bits wide ? > > > >Better may be 32 io in 44 pin packages, and use 5 packages spread on the > >board(s). > >CPLDs come in 32/64/128/.. macrocells, the better ones can pack a shift > >and latch > >into one macrocell. Prices are appx $1/32MC > > Is the price per IO pin goes up with larger CPLD's (e.g. >100 pins) or > is it cheaper to have one big CPLD ? We can go both ways depending on > which option is cheaper. > > >> > >> 5. Can be easily converted to a mask based equivalent chip (a full > >> ASIC is not possible at this stage, maybe for second generation). > >> > >> 6. Cost of the masked version is very critical (and having a > >> reasonable conversion/tooling cost is also very nice to have). > > > >So too are the volumes :) - what is the budget per I/O pin ? > > 1c per I/O in large quantities will be OK.Article: 44355
5V will still be OK and I noticed that most vendors have 5V offerings. The question is, which one to use. Tal On Tue, 18 Jun 2002 08:06:48 -0700, Austin Lesea <austin.lesea@xilinx.com> wrote: >Ted, > >What you are asking for is very old technology (anything > 5V is larger than >0.35u). > >I doubt it exists anymore. > >Austin > >ted_jmt@zapta.com wrote: > >> >> >> >> 2. Must work on 5V (or higher) >> > >> >Interesting request - How much higher - and for what loads ? >> >> 10V will be optimal. Current requirements are very very low (250uA is >> more than enough) >> >> > >> >150 i/o is a lot in one package - what is this driving ? >> >( are all the loads in one place ? ) >> > >> >Is the IO by Serial or parallel BUS, 8 or 16 bits wide ? >> > >> >Better may be 32 io in 44 pin packages, and use 5 packages spread on the >> >board(s). >> >CPLDs come in 32/64/128/.. macrocells, the better ones can pack a shift >> >and latch >> >into one macrocell. Prices are appx $1/32MC >> >> Is the price per IO pin goes up with larger CPLD's (e.g. >100 pins) or >> is it cheaper to have one big CPLD ? We can go both ways depending on >> which option is cheaper. >> >> >> >> >> 5. Can be easily converted to a mask based equivalent chip (a full >> >> ASIC is not possible at this stage, maybe for second generation). >> >> >> >> 6. Cost of the masked version is very critical (and having a >> >> reasonable conversion/tooling cost is also very nice to have). >> > >> >So too are the volumes :) - what is the budget per I/O pin ? >> >> 1c per I/O in large quantities will be OK.Article: 44356
This is a fundamental misunderstanding. Th BlockRAMs in all Virtex devics are true dual-port memories. If you use one port to write and the other one to read, you have complete freedom: different addresses, different CE, and different clocks on the two ports. You can also use both port to read, or both ports to write, but using one port for write and the other one to read is the most often used option. Note that the write port also has a read output ( that may be the source of your misunderstanding). That data output usesthe ame address as is used for the write operation. You can safely just ignore that data output. The Virtex BlockRAM gives you complete freedom to access the two ports. The only limitation, if you want to call it that, is that the read operation is synchronous, i.e. requires a clock edge. But even that is an advantage in many systems. Peter Alfke, Xilinx Applications Nagaraj wrote: > Hi, > I am using Xilinx Virtex series devices which provides BlockRAMs. > However instantiating or inferring BlockRAMs has lot of its own > stringent constraints like read and write address should be same, etc. > If I want to implement a memory module in the FPGA (memory should be > read when READ transits from low to high and CS is high, memory should > be written into when WRITE transits from low to high and CS is high) > with different read and write address, synthesis tool doesn't infer a > BlockRAM. > >Article: 44357
Ted, OK. 5V. Lots of choices. Austin ted_jmt@zapta.com wrote: > 5V will still be OK and I noticed that most vendors have 5V offerings. > > The question is, which one to use. > > Tal > > On Tue, 18 Jun 2002 08:06:48 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > >Ted, > > > >What you are asking for is very old technology (anything > 5V is larger than > >0.35u). > > > >I doubt it exists anymore. > > > >Austin > > > >ted_jmt@zapta.com wrote: > > > >> >> > >> >> 2. Must work on 5V (or higher) > >> > > >> >Interesting request - How much higher - and for what loads ? > >> > >> 10V will be optimal. Current requirements are very very low (250uA is > >> more than enough) > >> > >> > > >> >150 i/o is a lot in one package - what is this driving ? > >> >( are all the loads in one place ? ) > >> > > >> >Is the IO by Serial or parallel BUS, 8 or 16 bits wide ? > >> > > >> >Better may be 32 io in 44 pin packages, and use 5 packages spread on the > >> >board(s). > >> >CPLDs come in 32/64/128/.. macrocells, the better ones can pack a shift > >> >and latch > >> >into one macrocell. Prices are appx $1/32MC > >> > >> Is the price per IO pin goes up with larger CPLD's (e.g. >100 pins) or > >> is it cheaper to have one big CPLD ? We can go both ways depending on > >> which option is cheaper. > >> > >> >> > >> >> 5. Can be easily converted to a mask based equivalent chip (a full > >> >> ASIC is not possible at this stage, maybe for second generation). > >> >> > >> >> 6. Cost of the masked version is very critical (and having a > >> >> reasonable conversion/tooling cost is also very nice to have). > >> > > >> >So too are the volumes :) - what is the budget per I/O pin ? > >> > >> 1c per I/O in large quantities will be OK.Article: 44358
But wouldn't a perl script that looks at net names and uses those names to rename the primitives that drive them be a joy? Imagine being able to specify a syn_keep on a net and have the LUT or the MUXCY that drives it be NAMED the same as that net! I've done it manually a few times for a few signals as I've investigated timing. It should be something perlizable but I'm not a perl guy. I still haven't gotten reason #1 why the primitive that drives a net isn't automatically named the same as the net as occurs with all the registers. Does anyone have any thoughts? Simulator troubles, perhaps? Ray Andraka wrote: > I did get a note from Synplicity stating that their "policy is to not touch > instantiated stuff so we would consider this a bug", which is includes both the > muxcy bit and the FDREs, so perhaps there is some hope after all. As you know, I > abhor having to run a perl (or other) script on the netlist after synthesis. It is > one more tool that gets a chance to muck up your design and one more that the > customer can forget to use later, which generates a support call (usually at the > worst possible time). > > Rick Filipkiewicz wrote: > > > John_H wrote: > > > > > The manual MUXCY chain I had problems with going from 7.0.3 to 7.1 is now > > > working with the new mapper but the FDRE primitive is still being optimized, > > > so Synplify still knows better than I do about some instantiations :-) > > > > > > > > > > O.k. so it looks like Synplify are *determined* to optimise everything, no > > matter what our (esp. Ray's) opinion might say to the contrary [with this sense > > of righteousness I'd guess they must be s/w engineers :-)]. > > So the only action we can take is defensive and fix it systematically. > > > > o Perl hack the Synplify black-box libs to put some easily recognisable string > > in front of the prim names. e.g. > > > > ????_synth_tool_thinks_it_knows_better_than_me > > > > [Replace ???? with aggrieved word of choice]. > > > > o Pre-process the source code looking for Xilinx prim instantiations and add the > > extra string. Easier in Verilog than VHDL I think. Perl's good for this. > > > > o Use Perl [actually ancient sed would do this] to remove the strings from the > > resulting EDIF. > > > > o (possibly) set up an auto-email that sends a bug report to Synplicity every > > time the 2nd Perl script runs. > > > > In fact the first step might not be needed since the second one could generate a > > list of prim instantiations, go get the relevant definitions from the BB lib, > > edit the name(s), and tack the results onto the bottom of the source file. > > > > I accept Ray A's reservations on this but needs must .... > > -- > --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 > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 44359
Thanks for the suggestion. I will have a look at it. Doug "newman" <newman5382@aol.com> wrote in message news:e6038423.0206180614.ecd018a@posting.google.com... > Doug, > Very interesting. I believe that if you want a maximal length > sequence, one needs to use a primitive polynomial of degree 7 for a > GF(128). I am not an expert on this subject, but a book I have read, > and keep re-reading is Error Coding Cookbook by C. Britton Rorabaugh. > > Hope this helps, > > NewmanArticle: 44360
for a good survey of possible usage of BlockRAM, check:
http://www.fpgacpu.org/usenet/bb.html
--
Domagoj Babic
domagoj (et) engineer.com
"Nagaraj" <nagaraj@accord-soft.com> wrote in message
news:9c782518.0206172134.1b93b7@posting.google.com...
> Hi,
> I am using Xilinx Virtex series devices which provides BlockRAMs.
> However instantiating or inferring BlockRAMs has lot of its own
> stringent constraints like read and write address should be same, etc.
> If I want to implement a memory module in the FPGA (memory should be
> read when READ transits from low to high and CS is high, memory should
> be written into when WRITE transits from low to high and CS is high)
> with different read and write address, synthesis tool doesn't infer a
> BlockRAM.
>
> My question is, when the embedded memory can't be used as a full
> fledged memory, why are they included in the gate count of the device?
> For the cases like my application, I have to buy a higher gate count
> device (investing too much extra money). For example, if I want 32K
> bits of memory in my design, I need to realize it with Distributed RAM
> or Flip Flops. Hence I need more slices, higher gate count device and
> all the blockRAM blocks are wasted.
> (Unfortunately the option in Xilinx 4.2i "map slice logic into unused
> block RAMs" doesn't seem to work).
>
> Can anybody please suggest some solutions/alternatives (I have to
> use Virtex series devices).
Article: 44361I meant ADA/IDE spec: the spartan will interface with a hard drive. I'm not familiar with IBIS models, but I bet I can find it easily for HDDs... Austin Lesea wrote: > Stéphane, > > I do not know what an ATA bus is, so I can not answer. As long as the IO > drivers do not pull up to greater than Vcco + 0.5V with current more than > 10 mA, no resistor is required. A quick IBIS simulation of the ATA > output into a capacitive load would show if this is true. Do you have > the IBIS models for the ATA bus driver? Is there a website for them? > > The resistor is required if one is able to source current at greater than > Vcco + 0.5V to the Virtex input diode clamp. > > Austin > > Stéphane Guyetant wrote: > > > Hi all, > > > > after reading virtex "5V tolerant I/Os" > > (see http://www.xilinx.com/products/virtex/techtopic/vtt002.pdf ) > > and Spartan II functional description, I would say that I can use a > > Spartan-II > > (PQ208 package) with all VccO=3.3V in LVTTL mode directly on a 5V ATA > > bus > > with no need of resistor or buffering. Right? > > > > Any comment/suggestion appreciated! > > Thx, > > StephaneArticle: 44362
Nice, perhaps, but not at the cost of having yet another tool in the chain.
John_H wrote:
> But wouldn't a perl script that looks at net names and uses those names to rename the
> primitives that drive them be a joy? Imagine being able to specify a syn_keep on a net
> and have the LUT or the MUXCY that drives it be NAMED the same as that net! I've done
> it manually a few times for a few signals as I've investigated timing. It should be
> something perlizable but I'm not a perl guy.
>
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44363Hi ALL, Its me again, first I want to thank earlier contributors to my subject. I am still looking for more comments before I take the plunge. So far I have seen XESS, TRENZ, BURCH etc Europian boards cost 2X more for less fns. Anyway I am still undecided! CheersArticle: 44364
"Jim Stewart" <jstewart@jkmicro.com> schrieb im Newsbeitrag news:971EEFE8675D4CBD.71FB55547A613B69.D3C989D76578FDBE@lp.airnews.net... > Does the DLC4 aka Xchecker programmer work with the iMPACT programming > software bundled with WebPack? If not, is there an inexpensive NO. > programmer available or a simple way to integrate the old Foundation There is the schematics of the parallel cable 3 available on the Xilinx homepage. > JTAG programmer (which works fine with the DLC4) into the WebPack tool > chain? Just start it sepaerately. -- MfG FalkArticle: 44365
"Nagaraj" <nagaraj@accord-soft.com> schrieb im Newsbeitrag news:9c782518.0206172134.1b93b7@posting.google.com... > Hi, > I am using Xilinx Virtex series devices which provides BlockRAMs. > However instantiating or inferring BlockRAMs has lot of its own > stringent constraints like read and write address should be same, etc. > If I want to implement a memory module in the FPGA (memory should be > read when READ transits from low to high and CS is high, memory should > be written into when WRITE transits from low to high and CS is high) Sounds like a classic asynchronous microcontroller bus, isnt it? FPGAs are not designed to attatch to such busses directly, especially not the BlockRam, since it is synchronous. "Abusing" a FPGA as a SRAM replacement ist very econimical. > with different read and write address, synthesis tool doesn't infer a > BlockRAM. Especially in this case, synthesis tools are not smart enought to infer BlockRam automatically. But this is not a big issue, sionce if you do it manually (by inferring is), you have much better control over its operation. > My question is, when the embedded memory can't be used as a full > fledged memory, why are they included in the gate count of the device? Why cant it? It can easyly, but no so easyly on a old, asynchronous bus. > For the cases like my application, I have to buy a higher gate count > device (investing too much extra money). For example, if I want 32K > bits of memory in my design, I need to realize it with Distributed RAM You dont. The are ways to connect BlockRam to such asynchronous busses. Been there, do that. -- MfG FalkArticle: 44366
Hi all, I need these libraries for synthesizing partial configurations on this part. I'm using an old card Hot Works from VCC which comes with software for PC only (Xact Step 6000 series and free Velab VHDL structural compiler), and searching in web I have seen that it exists a library in Synopsys format which comes with Solaris Workstation CD, but I dont have this CD. Doed anyone know where can I get these libraries (a website or anyone can send me)? Thanks.Article: 44367
Kevin Brace wrote: > > hamish@cloud.net.au wrote: > > > > > > What does "bubble up" mean? > > > > Rick already explained it correctly, but the term "bubbling up > tri-state buffers" means when the design hierarchy is kept, moving > tri-state buffers to the top of the hierarchy, and converting them to > OBUFT or IOBUF IO pads. > LeonardoSpectrum's manual uses this term, and that's where I picked it > up. > > > Do you mean push-through? If so you must be the only person on this > > newsgroup who thinks that's a desirable feature. > > > Nope, Synplicity's CTO is the guy who thinks tri-state > push-through is a desirable feature. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) Ok, bubble up is now clear, but what the heck is "CTO"? -- 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: 44368
The point is, that Virtex BlockRAMs are synchronous RAMs, similar to modern cache RAMs, for example like IS61SP25616 by ISSI. The protocol for these RAMs is completely different to the old fashioned asynchronous SRAMs (62256 and the like) The synthesis tools can not infer you RAM, because asynchronous edge trigged write strobes can not be implemented by BlockRAMs. The synchronous approach is easier and safer to use, and often it is faster because of pipelining (though sometimes the 1 clock delay can be annoying) RTFM for the BlockRAMs, and you will see, that they are quite flexible. You definitely can have different addresses for simultaneous reads and writes. Kolja Sulimma nagaraj@accord-soft.com (Nagaraj) wrote in message news:<9c782518.0206172134.1b93b7@posting.google.com>... > Hi, > I am using Xilinx Virtex series devices which provides BlockRAMs. > However instantiating or inferring BlockRAMs has lot of its own > stringent constraints like read and write address should be same, etc. > If I want to implement a memory module in the FPGA (memory should be > read when READ transits from low to high and CS is high, memory should > be written into when WRITE transits from low to high and CS is high) > with different read and write address, synthesis tool doesn't infer a > BlockRAM. > > My question is, when the embedded memory can't be used as a full > fledged memory, why are they included in the gate count of the device? > For the cases like my application, I have to buy a higher gate count > device (investing too much extra money). For example, if I want 32K > bits of memory in my design, I need to realize it with Distributed RAM > or Flip Flops. Hence I need more slices, higher gate count device and > all the blockRAM blocks are wasted.Article: 44369
> >So too are the volumes :) - what is the budget per I/O pin ? > > 1c per I/O in large quantities will be OK. AFAIK 1c per I/O pin is pretty tight for packaging and test alone, even without a chip in it ;-)Article: 44370
Falk Brunner wrote: > > > Especially in this case, synthesis tools are not smart enought to infer > BlockRam automatically. But this is not a big issue, sionce if you do it > manually (by inferring is), you have much better control over its operation. > I don't think its really that synth tools are not ``smart enough''. Its more that to define fully dual port operation at the RTL level means being able to write code where the same variable [array of regs in Verilog] is written to in 2 different asynchronous `processes' [always blocks in Verilog]. This is, normally and for obvious reasons, a fundamental no-no for synthesisable code (and its not so hot for testbench code either!) since it clearly breaks the RTL simulation = post-synth simulation paradigm. I expect it would be possible to define a rigid enough template so that a synth tool can "see" that a DP RAM is being described, and not something else likely to cause simulation race conditions, along with some sort of ``caveat coder'' warning in the post synth reports like you get for inferred latches.Article: 44371
You might want to visit www.digilentinc.com FEMI wrote: > Hi ALL, > > Its me again, first I want to thank earlier contributors to my subject. > I am still looking for more comments before I take the plunge. > So far I have seen XESS, TRENZ, BURCH etc > Europian boards cost 2X more for less fns. > > Anyway I am still undecided! > > Cheers -- ***************************** Anna M. Acevedo Xilinx University Program 2100 Logic Drive San Jose, CA 95124 PH: (408) 879-5338 FAX: (408) 879-4780 Email: anna.acevedo@xilinx.com http://www.xilinx.com/programs/univ.htm *****************************Article: 44372
Hello, We brought board form the dini group, and so far, we have been really impressed by the features, and support we got from the company. http://www.dinigroup.com/products/3000k10.html regards, cyrille "FEMI" <femioye@hotmail.com> wrote in message news:aenqbo$gl$1@paris.btinternet.com... > Hi ALL, > > Its me again, first I want to thank earlier contributors to my subject. > I am still looking for more comments before I take the plunge. > So far I have seen XESS, TRENZ, BURCH etc > Europian boards cost 2X more for less fns. > > Anyway I am still undecided! > > Cheers > > > >Article: 44373
Hello, this is I am sure a silly question, but what does tran means in verilog code? regartds, CyrilleArticle: 44374
Benjamin Todd wrote: > I had this problem with initialisation of block ram - not i a Virtex, but in > a Spartan-II, I think that these problems are related > > _The syntax given in the xapps doesn't work_ > namely the synopsys_dc_script syntax > > It looks like your a verilog designer, I can't really comment on the valid > method for the verilog, but I do know that > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= > 1&getPagePath=10695 > > provided the correct syntax for the BlockRam initialisation in VHDL, there > surely exists a similar page for Verilog > > HTH > > -- > Benjamin Todd > European Organisation for Particle Physics > SL SPS/LHC -- Control -- Timing Division > CERN, Geneva, Switzerland, CH-1211 > Building 864 Room 1 - A24 For Verilog and Synplify as the synth tool you might try the `xc_props' synthesis directive either at the RTL level via the pragma: ... /* synthesis xc_props="INIT_00=..." xc_props="INIT_01=..." ... */; after the RAM instantiation. The downside is that I have a horrible sneaking suspicion that the pragma has to be all on one line [how I hate comment based pragmas, IMV they're the work of the devil. For all that I'm a Verilog bigot VHDL really does score here.]. If so then you can do the same thing via a .sdc synthesis control file.
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