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
Use SRL16's. Write shifts the data in, read is accomplished with a simple
up-down counter that counts up for write, down for read. Nice because only one
counter is needed, and that counter provides a count of how many words are in
the fifo too.
"Børge Strand" wrote:
> I'm working on a digital oversampling filter where I need some really small
> FIFOs (2 to 16 words long). The width is 16 to 24 bits.
>
> What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> probably need at least 8 of them. The FIFOs in the Core Generator are
> generally longer that what I need. Latency is no problem in my design, and
> the clock speed is rather low. Reads and writes to/from the FIFO will be
> synchronous to the clock.
>
> Any feedback wellcome!
>
> Regards,
>
> Børge
--
--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: 5152624 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex. With almost 400 bits, your best bet is using the dual-ported BlockRAM, organized 16 bits wide and 256 deep ( since you cannot get 32 width) Since your design is synchronous and slow, I would use both ports in parallel in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you time-multiplex the addresses for writing and reading ( only 4 bits!). That still wastes 90% of the RAM, but seems to be the simplest and cheapest approach. An asynchronous or very fast design would have to be totally different. Hilsen fra Peter Alfke, Xilinx Applications =============================== "Børge Strand" wrote: > I'm working on a digital oversampling filter where I need some really small > FIFOs (2 to 16 words long). The width is 16 to 24 bits. > > What is the recommended way to implement such FIFOs in a Spartan IIE? I will > probably need at least 8 of them. The FIFOs in the Core Generator are > generally longer that what I need. Latency is no problem in my design, and > the clock speed is rather low. Reads and writes to/from the FIFO will be > synchronous to the clock. > > Any feedback wellcome! > > Regards, > > BørgeArticle: 51527
I think Ray Andraka's suggestion using SRL16s is better, it only needs about 30 LUTs. But if you are short on LUTs and rich on BlockRAMs, my suggestion would be better. Peter Peter Alfke wrote: > 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex. > With almost 400 bits, your best bet is using the dual-ported BlockRAM, > organized 16 bits wide and 256 deep ( since you cannot get 32 width) > Since your design is synchronous and slow, I would use both ports in parallel > in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you > time-multiplex the addresses for writing and reading ( only 4 bits!). > That still wastes 90% of the RAM, but seems to be the simplest and cheapest > approach. > An asynchronous or very fast design would have to be totally different. > > Hilsen fra > Peter Alfke, Xilinx Applications > =============================== > "Børge Strand" wrote: > > > I'm working on a digital oversampling filter where I need some really small > > FIFOs (2 to 16 words long). The width is 16 to 24 bits. > > > > What is the recommended way to implement such FIFOs in a Spartan IIE? I will > > probably need at least 8 of them. The FIFOs in the Core Generator are > > generally longer that what I need. Latency is no problem in my design, and > > the clock speed is rather low. Reads and writes to/from the FIFO will be > > synchronous to the clock. > > > > Any feedback wellcome! > > > > Regards, > > > > BørgeArticle: 51528
Ray Andraka wrote: > > No, the router actually takes considerably longer than it did under 3.3 if the timing > constraints are tight. That was what I meant - I expected a faster completion on a router that followed the placement, so expected the older model to be faster. - just checking that was the case. Seems to me, in this Open FPGA discussion, that it would be better to have Open Communication with the tools designers, than so called 'Open Tools'. Modern SW design means the SW writers rarely use the tools, so the flow of information on how they fail, or worsen with revisions, is very important. Often the test examples are selected to test the 'new' features, and it is easy to loose sight of degraded performance in other cases. > Unfortunately, one is forced to use the later versions for any of the > virtex2 or spartan2E devices. To echo Peter A, here, a good question is WHY ? With such an apparent performance branch, perhaps Xilinx should a) add these devices to the older flows, or b) hook the order routers into the new flows. Looks like a classic version control creepage problem to me.... > > Jim Granville wrote: Since a 'heavily floorplanned designs' has most of placement > work done, one could expect the routers to finish much faster. > > > > Do you see much difference in the completion times of the 3.3 tools, vs > > 5.1 tools ? > > > > It's a common problem, supposedly smarter tools being harder to > > control, and/or > > giving dumber results.. > > > > -jgArticle: 51529
In article <e9486eb9.0301141538.3031355@posting.google.com>, spam_hater_7@email.com says... > See earlier thread about signal (net, language) naming conventions. > > There is a reason that we use them! Sure. There are strong naming conventions in use. However, chip_unit_subunit_reg_b_out becomes chip_unit_subunit_mux_b_in and perhaps chip_unit_reg_a_out(62) may become chip_unit_subunit_cr_of (for example). There are three names for the same register bit. The particular case I'm thinking about has two more names associated with the signal because the size of the physical registers (and muxes) is different than the size of the architected registers. Confusing when reading the logic, sure. The names all have a purpose though. > You may consider doing just that; pick a naming convention, and start > cleaning up the code. It will make it much easier for the -next- bug. No, mucking with a working design wouldn't be a good idea at all. I did say it's a *big* design. It would be CLM (Career Limiting Move). > Couple of perl scripts, emacs with vhdl-mode, and a fair amount of time. Since the design is hundreds of man-years worth of effort, I guess it would take a fair amount of time to convert it to something *I* liked. ;-) Note that I'm taking the schematic/HDL discussion beyond the realm of FPGA designs. I'm interested in the general applicability of both. I'm currently working on a large custom chip, though I had much more fun when I was doing FPGAs (which is why I follow this NG). :-( ---- KeithArticle: 51530
In article <v29ho8p9qj6u5d@corp.supernews.com>, austin@da98rkroom.com says... > Keith, > > > > Well, it depends. If you have a schematic library that allows you to > draw a > > > flow diagram and makes it drag and drop, it's REALLY easy...and easy to > > > do...and easy to read. > > > > Doesn't that make it more of an HDL rather than schematic? > > How? There's no HDL involved at all. Symply schematic blocks and symbols. > > > There is > > some "synthesis" going on then. Perhaps I don't understand your tool. > > There is no synthesis. Simply hierarchical symbols, and underneath those > symbols are schematics, or other blocks. The very bottom level is gates, > but above that, it's functional blocks. Like a single symbol for a counter, > or a single symbol for a CRC generator... I guess I don't quite see the process yet. The top level is a schematic block, and the bottom level is gates, but the intermediate hierarchical objects are flow charts? The mainframe logic designers I worked with ~ten years ago used flow charts for the entire design. The designs certainly were synthesized (and simulated) from the flow charts. > > > > The design is simply too large > > > > to make it practical though. > > > > I believe that generating schematics from this VHDL would be > > impractical. > > Ah, yes. I understood that to mean that using schematics FOR that design > was impractical because of the size of the design. That too. The mainframes of the 70s-80's were designed using schematics. The logic diagrams filled carts for a single system unit. Call me skeptical on designs this size. > > > Er, yeah. That's why the fast PCI cores are done in schematics ;-) > > > > PCI is fast?! > > In a 4k, getting it to run at 33MHz is fast, and getting PCI-X to run at > 133MHz is fast as well. So, yes, PCI IS fast. For programmable logic, sure. I didn't mean PCI(-X) was an easy design. 133MHz isn't fast at all for a custom design. I wuz just twitting ya' a tad. ;-) > > > Well, then...DON'T USE ORDAD! > > > > Ordad? Tell us how you really feel! Don't hold it in! > > I can't believe that they actually have the nerve to charge for such a gross > schematic package...as $9.99 shareware, it's pretty good, but as a real > schematic tool, it just doesn't work well. The PCB tools are excellent > though...which I find kind of funny. That's about what I felt when I was learning to use Orcad. It is a pretty miserable interface. > >One of the best decisions I made was to go > > with the Synplicity tools. > > Yes, they, specifically, have come a LONG way and as far as for FPGA use, > are exceptional, especially with the RTL viewer. I am very happy with > Synplicity. I don't think I could have gotten anywhere with VHDL/FPGAs without the HDL Analyst. It took me a couple of months to figure out what language constructs synthesized to the structure I wanted. ---- KeithArticle: 51531
I am very new to Xilinx tools so I apologise for being vague. I tried using the Project Navigator and got the following error: Compiling vhdl file jc2_top.vhd in Library work. ERROR:HDLParsers:3014 - jc2_top.vhd Line 2. Library unit std_logic_1164 is not available in library ieee. I then tried the XST synthesis tool from a command line using the following script: run -ifn jc2_top.vhd -ifmt VHDL -opt_mode SPEED -opt_level 1 -ofn jc2.ngc -p 2s15-tq144-5 I get the same error message. Thanks Andrew RogersArticle: 51532
To be fair, Xilinx is looking into the problem. There definitely is a problem industry
wide of the software designers not really knowing how their tools are used. I don't think
there were heavily floorplanned designs in the test suite. The claims I've heard was the
PAR ran faster and got better results in 80% or so of the test designs. Unfortunately, my
designs seem to invariably fall in the other 20%. I'm sure most of the test designs were
more of what is typically done by average FPGA designers...fat slow designs that are good
enough in applications that are not particularly piece-part cost sensitive.
Jim Granville wrote:
> Ray Andraka wrote:
> >
> > No, the router actually takes considerably longer than it did under 3.3 if the timing
> > constraints are tight.
>
> That was what I meant - I expected a faster completion on a router
> that followed the placement, so expected the older model to be faster.
> - just checking that was the case.
>
> Seems to me, in this Open FPGA discussion, that it would be better to
> have
> Open Communication with the tools designers, than so called 'Open
> Tools'.
> Modern SW design means the SW writers rarely use the tools, so the flow
> of
> information on how they fail, or worsen with revisions, is very
> important.
>
> Often the test examples are selected to test the 'new' features, and
> it is easy to loose sight of degraded performance in other cases.
>
> > Unfortunately, one is forced to use the later versions for any of the
> > virtex2 or spartan2E devices.
>
> To echo Peter A, here, a good question is WHY ?
>
> With such an apparent performance branch, perhaps Xilinx should
> a) add these devices to the older flows,
> or
> b) hook the order routers into the new flows.
>
> Looks like a classic version control creepage problem to me....
>
> >
> > Jim Granville wrote: Since a 'heavily floorplanned designs' has most of placement
> > work done, one could expect the routers to finish much faster.
> > >
> > > Do you see much difference in the completion times of the 3.3 tools, vs
> > > 5.1 tools ?
> > >
> > > It's a common problem, supposedly smarter tools being harder to
> > > control, and/or
> > > giving dumber results..
> > >
> > > -jg
--
--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: 51533
If you are short enough on luts for the SRL16 to be too expensive, you are likely
also too short to construct the two address counters plus mux logic plus population
count using LUTs that are close enough to the BRAM to not be a timing problem. In
that case, I wouls look at the entire design to determine what parts would get the
most bang for the buck for implementation in the block RAM instead of in LUTs.
Peter Alfke wrote:
> I think Ray Andraka's suggestion using SRL16s is better, it only needs about 30
> LUTs.
> But if you are short on LUTs and rich on BlockRAMs, my suggestion would be
> better.
> Peter
>
> Peter Alfke wrote:
>
> > 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex.
> > With almost 400 bits, your best bet is using the dual-ported BlockRAM,
> > organized 16 bits wide and 256 deep ( since you cannot get 32 width)
> > Since your design is synchronous and slow, I would use both ports in parallel
> > in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you
> > time-multiplex the addresses for writing and reading ( only 4 bits!).
> > That still wastes 90% of the RAM, but seems to be the simplest and cheapest
> > approach.
> > An asynchronous or very fast design would have to be totally different.
> >
> > Hilsen fra
> > Peter Alfke, Xilinx Applications
> > ===============================
> > "Børge Strand" wrote:
> >
> > > I'm working on a digital oversampling filter where I need some really small
> > > FIFOs (2 to 16 words long). The width is 16 to 24 bits.
> > >
> > > What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> > > probably need at least 8 of them. The FIFOs in the Core Generator are
> > > generally longer that what I need. Latency is no problem in my design, and
> > > the clock speed is rather low. Reads and writes to/from the FIFO will be
> > > synchronous to the clock.
> > >
> > > Any feedback wellcome!
> > >
> > > Regards,
> > >
> > > Børge
--
--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: 51534Andrew Rogers wrote: > I am very new to Xilinx tools so I apologise for being vague. > > I tried using the Project Navigator and got the following error: > > Compiling vhdl file jc2_top.vhd in Library work. > ERROR:HDLParsers:3014 - jc2_top.vhd Line 2. Library unit std_logic_1164 > is not available in library ieee. > > I then tried the XST synthesis tool from a command line using the > following script: > > run > -ifn jc2_top.vhd > -ifmt VHDL > -opt_mode SPEED > -opt_level 1 > -ofn jc2.ngc > -p 2s15-tq144-5 > > > I get the same error message. > > Thanks > Andrew Rogers > Answer to my own question! It seems that my XILINX environment variable should not have a trailing slash or back-slash. I discovered the problem when I ran XST on Linux using Wine. First I set the XILINX variable export XILINX=/mnt/win_d/xilinx/ with the slash, based on the line in my Windows autoexec.bat SET XILINX=D:\XILINX\ Anyway setting the env variable without the trailing slash solved the problem, at least while running XST from Linux using Wine. I'm sure that the solution will also work if applied to Windows autoexec.bat but haven't tried that yet. Regards Andrew RogersArticle: 51535
Keith, > I guess I don't quite see the process yet. The top level is a schematic > block, and the bottom level is gates, but the intermediate hierarchical > objects are flow charts? The top level of the schematic is, well, the top level. There are blocks on it, and the blocks may or may not be attached, and by attached, I mean have signals between them. Below each block is another schematic or an HDL file, or a "black box". Etc. You can create a hierarchy any number of blocks deep, with the last block you can push down through being either gates, a black box, or some HDL. A schematic is nothing but a page with symbols on it, and connections. A flow chart (done in schematics using libraries) is nothing but a bunch of flow chart symbols, and their attachments. Each flow chart symbol is just like any other block, but it is used for a flow chart. It is just a symbol with an underlying schematic, HDL or black box. > The mainframe logic designers I worked with ~ten years ago used flow > charts for the entire design. The designs certainly were synthesized > (and simulated) from the flow charts. Are you talking board level schematics, chip schematics or what? I don't know the tool you are talking about. > > Ah, yes. I understood that to mean that using schematics FOR that design > > was impractical because of the size of the design. > > That too. The mainframes of the 70s-80's were designed using > schematics. The logic diagrams filled carts for a single system unit. > Call me skeptical on designs this size. That's why you use hierarchy. The more abstract (to a point, of course) you can define the functions, the better your hierarchy. > For programmable logic, sure. I didn't mean PCI(-X) was an easy design. > 133MHz isn't fast at all for a custom design. > > I wuz just twitting ya' a tad. ;-) > Yeah, well "twit" me after you've implemented a PCI-X design and see how "fast" it really is ;-) > I don't think I could have gotten anywhere with VHDL/FPGAs without the > HDL Analyst. It took me a couple of months to figure out what language > constructs synthesized to the structure I wanted. A fundamental gripe I have with synthesis tools. They SHOULD provide a document that states EXACTLY what a construct gets synthesized to. We used to do that when I wrote compilers, and I believe it's even more important to do for hardware...but for some reason, people like the "it's done by magic" philosophy. Sigh. Regards, AustinArticle: 51536
"Austin Franklin" <austin@da98rkroom.com> writes: > A fundamental gripe I have with synthesis tools. They SHOULD provide a > document that states EXACTLY what a construct gets synthesized to. They do. It's in one of the report files. I often look at it to make sure that I'm getting something reasonable.Article: 51537
In article <v28pgpdr4uo638@corp.supernews.com>, austin@da98rkroom.com says... > Michael, > > > Basically, schematic entry tools are still in use only because people > > without a software background are still allowed into a FPGA design > > field. > > Your statement is just simply so foolish I have to believe you simply are > not serious. If you are in fact serious, please let me know, so I can > 'splain to you just how foolish such a statement is, for so many, many > reasons. Lucy, you have some 'splainin' to do! ---- KeithArticle: 51538
Hi, I'm not even a newbie with respect to fpgas (I spend most of my time on supercomputers) but am curious as to how good the tools are for developing fpgas. For example, if someone wrote a fixed point fft in C (or vhdl using the C-like programming part) and fed it to current fpga tools, how would the output compare to someone with several years of experience doing whatever was needed to make it run as fast as possible? Would it be half as fast? 1/100th? worse? And where are the worst problems? Is it vhdl compilation? place and route? Something else? MattArticle: 51539
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhlm1loob3.fsf@ruckus.brouhaha.com... > "Austin Franklin" <austin@da98rkroom.com> writes: > > A fundamental gripe I have with synthesis tools. They SHOULD provide a > > document that states EXACTLY what a construct gets synthesized to. > > They do. It's in one of the report files. I often look at it to make > sure that I'm getting something reasonable. Eric, I don't think you understand what I am talking about. What I am looking for is a gate level description of what a construct will synthesize to. It is not a standard, so it can vary from tool to tool, and from release to release...and can change for some unrelated reason, just because that's the way synthesis tools work. I don't want to run the tools and play guessing games with what the tool is going to output. It should be documented, so when I code, I KNOW what the hardware will be. AustinArticle: 51540
Hi, I looked at Virtex II pro architecture.What are the functions of WG4, WG3, WG2 and WG1?I noticed there are 8 inputs to each LUT. Are they forming a 2^8 by 1 LUT tables or two 16 by 1 LUTs indivisually? Thank you very much! sincerely ------------- Kuan Zhou ECSE departmentArticle: 51541
"Austin Franklin" <austin@da98rkroom.com> writes: > I don't want to run the tools and play guessing games with what the tool is > going to output. It should be documented, so when I code, I KNOW what the > hardware will be. The tool doesn't always output the same thing for a given construct. A lot of things can influence it. A manual like you propose would be huge, and would almost always be out of date. Have you seen such a manual for a C compiler? I haven't. And that's an easier problem, because there are few constraints on the compiler output. If you care about what's generated, you should look at the reports produced by the synthesizer. That will tell you what you want to know.Article: 51542
bktan1974@netscape.net (John Tan) wrote in message news:<eb4dd21b.0301120804.6a2e6729@posting.google.com>... > Hi, what is the merit & constraint of each of these design entry > methods > > - schematic design > - VHDL > > i have heard pple saying any changes in schematic entry, will cause > all timing to be changed and you got to check your timing again; is > this true ? ANd how about VHDL; is it really better? > > > I have last done a uni. project to implement a convolutional codec > using schematic entry method; and frankly i i can't imagine to program > the design in VHDL ...it's just too enormous the codes! I've been designing both H/W and S/W for far too many years (when I started, gates came 4 to a package, which was called a "bug"...). I've used both schematics and HDL for designs of various sizes. I am all for HDL, for the following reasons: * Schematics can make the design structure and data flow more visible? sure, if your design flows data from one end to another. Control signals, however, are usually a rat's-nest, which rather spoils the pretty picture. For documenting the design, use a graphical editor (I use Visio), and draw only the interesting stuff; I don't have to bother with all the random signals which makes a schematic functional (even clocks and resets!). * Documenting your design: of course you can document a schematic design, but if you write in HDL you can (and I do) comment EVERYTHING: each port, each decision, why I did it this way and not that way. The comments are there near the design itself and not in a separate file which I have to open as well, and which I will probably be too lazy to update on every design change. * Entering a design: I can type much faster than I can drag lines with a mouse. I can also create parameterized blocks and reuse them with no changes; a 4-bit counter and a 32-bit counter are the same. Will a schematic 4-bit counter be the same as a 32-bit counter? * Maintaining a design: say you need an up/down counter which counts between 5 and 27. In your schematics it wil be a mess of gates and FFs; after you haven't touched this part of the design for a few months, you'll have to scratch your head quite a lot to understand what it's supposed to do (been there, done that). In an HDL design, even if it's uncommented, you can understand what it does in a glance. * Navigating the design: most schematic tools have very poor search capabilities, compared to text editors. It's much easier to follow signals, especially as the display is much denser: I can view something like 100 lines of text at once, which can represent, for example, a state machine which will require many schematic pages. * Version Control: you can save schematics in a VCS; but how do you compare versions? once, long ago, I've thought of writing an application to read graphic representation of a schematic (using HP-GL, then used for most printing), and then overalying the output graphics on a display. After some thought, I gave it up and returned to the old method of overlaying the schematics on a light table - very hard work. In a text-based design, you can very easily compare version: aha! I've added a pipeline register here! so THAT is the bug! all in a few minutes. * Simulation & verification: if your design is a schematic, how do you simulate? usually you draw waveforms (or the text equivalent of writing test-vectors) - more of the same hard work. When your design is HDL, you can create an interactive test-bench (with the design, sadly not with you) and automate the whole process; run it at night and in the morning you see, before your first coffee, if it worked or not. All that said, I still belive that a person who has schematic design experience will usually create better HDL designs, the same way that a programmer who has Assembly code experience will usually write better high-level language code.Article: 51543
Hi Kuan, Which schematic tool are using in the ISE 4.2. For e.g. is it the FPGA editor, etc.. Regards Amit Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030114211435.25313A-100000@vcmr-86.server.rpi.edu>... > Hi, > I am using ISE 4.2 student version.But I can not find output pad in the > schematic tools.Does any one know how to add pins in the schematic design? > The help says you can find "add pins" from the Add menu,but I can not find > it. > > Thank you very much! > > sincerely > ------------- > Kuan Zhou > ECSE departmentArticle: 51544
> > Does anyone know what is the best choice for an fpga developement kit? > > Altera offers this kit for University student : > > http://www.altera.com/education/univ/kits/unv-kits.html > > I wonder if there are other supplier of boards like this (could be Xilinx > > too) that could compete with this. Are there third party manufacturer that > > are worth considering? > > Thanks > > David > > > I use a Trenz-electronic Xilinx Spartan II board (TE-XC2S) with 200k gates, quite a nice device to learn this exciting technique (cf http://www.trenz-electronic.de/prod/proden7.htm). Take also a look at http://www.fpga-faq.com/FPGA_Boards.htm Yours, Frederic BastenaireArticle: 51545
Thanks guys, What is happening is that the digital oversampler presents four (or eight) samples on consecutive positive clock edges. The oversampler itself decides when this is about to happen. (I can count there, but I prefere not to.) Then the oversampler stays silent for a while. However, the input samples to the oversampler have to have delays between them. The output from an oversampling filter is to be fed to the next oversampling filter at a more steady rate (i.e. not four samples and then long delay, but one sample - some delay - one sample -some delay, and so on). The output from the final oversampler goes to a DAC at a completely steady rate. So you see the need for FIFOs. In my prototype code I fill registers 0 through 3 or 7 and then read them at a later stage, but this makes timing pretty complicated. My filter will perhaps use 4 2x-oversamplers in 2 channels. That calls for 2 FIFOs which are 2 deep, 2 which are 4 deep, 2 which are 8 deep, and 2 which are 16 deep. So that means there's a bunch of really small FIFOs. The last one has to be 16 deep, the other ones can probably be trimmed down to depth 2, but I won't be able to reduce the count. And if all this works I'll connect it to my CD player and play Bach on it! -- Børge "Peter Alfke" <peter@xilinx.com> wrote in message news:3E259496.6D9D7A87@xilinx.com... > 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex. > With almost 400 bits, your best bet is using the dual-ported BlockRAM, > organized 16 bits wide and 256 deep ( since you cannot get 32 width) > Since your design is synchronous and slow, I would use both ports in parallel > in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you > time-multiplex the addresses for writing and reading ( only 4 bits!). > That still wastes 90% of the RAM, but seems to be the simplest and cheapest > approach. > An asynchronous or very fast design would have to be totally different. > > Hilsen fra > Peter Alfke, Xilinx Applications > =============================== > "Børge Strand" wrote: > > > I'm working on a digital oversampling filter where I need some really small > > FIFOs (2 to 16 words long). The width is 16 to 24 bits. > > > > What is the recommended way to implement such FIFOs in a Spartan IIE? I will > > probably need at least 8 of them. The FIFOs in the Core Generator are > > generally longer that what I need. Latency is no problem in my design, and > > the clock speed is rather low. Reads and writes to/from the FIFO will be > > synchronous to the clock. > > > > Any feedback wellcome! > > > > Regards, > > > > Børge >Article: 51546
The Xilinx docs. describe a command-line option to XST: set -xsthdpini <file> to be used to specify a "VHDL.INI" file, for use when a source project spans several logical libraries (I do have this right?) Q: Is there anywhere an example syntax of the VHDL.INI file? I can't seen to find one. TIAArticle: 51547
Hi, Is there any free HSPICE simulator available in the Web? Thanks SkillieArticle: 51548
Hello, We've got the following problem: Some time ago we finished a PCI interface card using a Spartan II FPGA and the Xilinx PCI core (3.3V). The card has been used in several computers since then and we have never had any problems with it. Recently we bought a new computer that also has to use this card, but it's equiped with PCI-X expansion slots. According to the PC's documentation the PCI-X slots are fully PCI 2.2 compliant. The Xilinx PCI core is also PCI 2.2 compliant so there should be no problem. Unfortunately it does not work ! As far as we can see the problem is not PC related since several other (ordinairy) PCI cards work well with the PCI-X slot. Has anybody ever got this to work properly ? Or has anybody got any idea on what might be wrong ? Harjo.Article: 51549
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0301141000.6baec97c@posting.google.com>... > Basically, schematic entry tools are still in use only because people > without a software background are still allowed into a FPGA design > field. The day management will finally realize how much money can be > saved by keeping these people (a.k.a. hardware engineers) out of all > but the simplest FPGA designs - the time of the schematics will be > over. > These HW guys can't spell "version control" !!! Enough said. > > bktan1974@netscape.net (John Tan) wrote in message news:< I wonder if you ever flew on a plane developed by SW engineers that did't need to visualize all it's parts to check if it made any sense. I wonder if you drive a car developed by SW engineers .... I wonder if you live in a house developed by SW engineers .... Why do Boing, GM,Ford, most all architects use 3d modelling SW to visulize, I guess it beets me. I surely hope that I never have to work for someone out of SW school thinks he's a wiz at HW, yeck I am remined of all the Bill Gates jokes , if MS ever designed a car... Please tell us what companies you have worked for so I can steer as far away as possible!! As a side note I would say the main reasons schematics are barely with us are many, Most of the EDA schematic tools were bloody awefull, non portable, no free viewers, dongeled to hell & back, buggy as hell, & written by SW twerps that never used their own tools, incompaible (until EDIF came along), poor cousins of the bigger tools. But a few were gems, (written by ASIC veterans). Example, you want to run a new wire between distant blocks across the hierarchy. In any HDL its a few mins work to edit the port lists and add the wires to all the intervening cells, but you'd have to compile it to know for sure. In VLSI/Compass, it was almost as easy but still took a few times longer, and that tool had true edit in place symbols that changed as you added the new ports & wires and it wasn't too dumb, interactive DRC, errors flashed up quickly, very Macish, a pleasure to use. Many ASICs were built with those tools but Cadence bought em out and junked everthing except the cell libs. In every other schematic tool I used since, the work load for such simple tasks was 10x Compass, no edit in place, you had to rip out the instances, go to symbol edit, change the symbol, reinstance into all locations where ripped, fight multiple versions, add the wires, no interactive DRC, even the redraw had to be used to clean up many draw errors. I shudder at the thought of how much time was wasted fighting the darn things. Alas, I miss Compass, it will never be the same. I also can still understand most all the schematics I ever worked on over 2 decades, I can't say the same for HDL unless it is very structural & quite recent. Wonder why? It doesn't have to be like that, as I said before, if only I could massage the auto generated sch output to make it more presentable,....
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