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
Prashant wrote: > Hi, > > I have an FPGA board from Altera that I use for my prototyping needs. > The board has a single FPGA on it and an oscillator for 40MHz. I have > to integrate this board with another board (type of second board > unknown as yet) and some issues with such an integration just hit my > head. There also may be issues I haven't thought of as yet. Guessed > this may be a question to ask people for advice. > > 1. Since the FPGA needs to work @ 40 MHz, can I get the same speeds on > the board. What sort of speeds can be expected from data transfers > using board interconnects between the two boards in question ? > Obviously, if it was slower than the 40MHz requirement I have, the > integration between the two boards would be impossible. But I haven't > seen a mention of the board speeds in the data sheet of the board. > This is probably a very common issue for a lot of prototyping that > goes on in the industry. Any ideas ? > > 2. Clock syncronization between the two boards is another issue. I can > think of one way to do it. Use a pll in one FPGA device and take an > output of the clock from this FPGA (FPGA 1). Supply this output clock > of FPGA 1 as the input clock to FPGA 2 on the second board. Would this > work and if so, Is this the right way ? What other ways would be used > if any ? Which would be more efficient in terms of clock skew ? > > 3. What design methodology would apply to integration of more than 2 > boards ? My guess is it would be similar to integration of 2 boards. > > 4. Is it possible to integrate a board with a Xilinx device to a board > with an Altera device ? Interfacing FPGAs from different vendors is not a problem as long as the logic levels match. And the speed ? You definitely have least problems when the clocks are in sync, eg by running from just one clock. Some chips have internal mutipliers, and for integer multiples they are in sync. If you have two different clocks a Flipflop, or rather two of them can do the synchonization. Wouldn't it even be possible to integerate everything into one device ? While a design spread over multiple chips are much harder to simulate, it might be cheaper to do a board with everything in one chip. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 51576
Terry Herter <tlh10@cornell.edu> wrote in message news:<3E24B39E.272225A5@cornell.edu>... > Sorry...should have been more informative. Looking for a 19" rackmount > system...with a passive backplane and a single board computer...6U type > size...etc. Desktop PCI in a more rugged frame... > > Thanks. > > "Nicholas C. Weaver" wrote: > > > In article <3E248F61.77E1748E@cornell.edu>, > > Terry Herter <tlh10@cornell.edu> wrote: > > >Off topic question...but I suspect many will have some insight... > > > > > >Looking for a good single board computer/passive backplane in a rack > > >mount. > > > > > >Can anyone suggest a good company to deal with, that just may be around > > >in a few years to come? > > > > How small/what backplane? > > > > Eg, Via makes a nice all-in-one PC motherboard (C3 processor, chipset, > > video, audio, 100 mb ethernet, USB2, firewire) which retails for <$150 > > with a 900 MHz processor, <$130 for a FANLESS 600 MHz processor, and > > is 17cm x 17cm in dimension (mini-ITX form factor) > > > > http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.edu google "single board computer/passive backplane in a rack" looks interestingArticle: 51577
Suppose 10 tap adaptive FIR filter and there are lots of zeros in input, say 2 out of 10. So I don't need 10 multipliers to muliply 10 inputs and coefs because of many zero inputs(I need 2 multipliers). After calculating sum of inner product I need to update the coefs. How to save multipliers to implement adaptive FIR for this case? ThanksArticle: 51578
In article <v2c27hcn3mmr95@corp.supernews.com>, austin@da98rkroom.com says... > 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. Ok, call me dense. If you push down the hierarchy to lower level schematics, I can see there is no "synthesis" going on. Eventually you'll end up with a schematic representation of a physical gate. However, if you push down to HDL you'll have a abstraction of that gate that is "synthesized" into the physical gate. I'm not sure where the flowchart comes in. Does it have a representation under it of a LUT/FF? Or is the physical construction "synthesized" from the flowchart function. > > > 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. Chip, module, board, frame, processor, complex. All schematics (or later, flowcharts). The tools were all internal. > > > 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. Hierarchy only goes so far. Sheer size can swamp the best thought out hierarchy. Eventually you need to flatten the hierarchy (placement, debug, etc.). These things caught us many years ago, which is why VHDL was chosen, I suspect. > > 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. Sure. A design guide for synthesis would be a great idea. I'm not sure how practical it would be though. Certainly a "template" to structure document would be goodness. I'd think this would be the corporate jewels for a company like Synplicity and not likely to be published for mere customers. OTOH, where it matters the design can be instantiated down to the primitives, which I realize is a vote for schematics. I had to do this to get to the Virtex carry chains/SRL16s/blockrams. Other places I did it to force the structure I thought would be the fastest. In many places speed simply doesn't matter and the design can be as abstract as the designer cares to make it. ---- KeithArticle: 51579
tsao wrote: > Thanks, > > tomorrow I'll bring my code to school > to compile it using DK1 and see if it fits, and if everything go > well, I'll post my Handle C source code somewhere. Is sure interesting ... >>If your 3D rendering pipeline is very roughly >> >>modeling >> lighting and transforms >> coordinate transforms and clipping >> triangles/quadrilaterals setup >> span rendering >> shading, texturing, and Z-buffer check >> >>Then the last 3-4 stages, the data intensive ones, much in the integer >>domain, can readily be done in an FPGA. See for example > > > Well, I thought those last stages still require floating point, > like zbuffer and shading(color interpolation), and texture coordinates > transforms. Anyway I'll see. Not really.. After clipping, you are in the integer domain, and even very small integers. (screen of 2048x2048 with subpixel resolution is still less than 16 bit, colors are around 8 bit, etc.) Largest is probably your z-buffer if you take 32 bits for it. (and here is the problem for the divider also ;-) cheersArticle: 51580
Jan Gray wrote: > Then the last 3-4 stages, the data intensive ones, much in the integer > domain, can readily be done in an FPGA. See for example > http://www.fpgacpu.org/usenet/render.html, but note the date and the target > FPGA (3K gates). These days I would recommend rendering in bands or tiles > and keeping the Z-buffer for the band/tile in block RAM. Also, low res > textures can probably fit in a block RAM texture store / texture cache. As long as he doesn't do any filtering on the textures, I think to render in bands is easier and faster. Because you just touch every pixel only once, the pixel/zbuffer read/write pipeline is probably still the slowest part of it.Article: 51581
All, I was wondering if anybody knows how fpga express (3.5) orders the states of the current_state register if I use enumerated data types (using one-hot). Like the following: type state_type is (IDLE, INIT, LOAD_1, LOAD_2, LOAD_3); signal CURRENT_STATE : state_type; after synthesis would CURRENT_STATE(0) be IDLE, CURRENT_STATE(1) be INIT, CURRENT_STATE(2) be LOAD_1, CURRENT_STATE(3) be LOAD_2, and CURRENT_STATE(4) be LOAD_3???? Or is it ordered the other way, or am I complete wrong??? Thanks in Advance, MikeArticle: 51582
rickman wrote: > Sounds to me like you are a software person rather than a hardware > designer, right? Let's just say the last time I designed hardware you could unsolder parts using a plain old soldering iron and a solder sucker :) But you're basically right. > When you write HDL descriptions of hardware, you don't > write the code thinking of the problem and let the tool generate its own > hardware to solve it like is often done in software development. > Although this works pretty well with most compilers, HDL synthesizers > are not as well developed. Normally a HDL developer will write his code > thinking of the solution and use the HDL to describe what his solution > should look like. This is a very different process. > > If you write HDL thinking of your solution then the tools work pretty > well. In that case your example above is not really practical since an > FFT written in C would not translate well at all into an HDL as normally > used. This seems to be a hint to my answer. I'll rephrase the question. There are companies that sell software that will take matlab or Handel-C and turn it into fpgas. So fft->fpga is possible. What I want to do is quantify how good that might be. There's another thread running about schematic entry vs vhdl that implies that vhdl is ok if it's used to describe data flow as opposed to serial process flow. This implies that the serial->data flow translation is not so good. How bad is it? If writing serial code generates an fpga that's half as fast as writing data flow then that's not bad. If it's a 1000 times slower and is 10 times the size then that's a serious problem. It's the usual assembly vs C tradeoff. Assuming the program is written using data flow, can a compiler do a good job of place and route or is this another case where the user has to get involved? Considering that the graph theory anywhere near this type of stuff is all NP I assume there is a problem. Since there are tools that allow people to help with this I'm sure there's a loss of efficiency by just letting the tool do everything. I just want to know how much of a loss there is. MattArticle: 51583
I am having problems locking the DLL on a SpartanII. The DLL will not lock on power up, or after configuration and will only lock after an asynchronous reset. The DLL is fed a 49MHz clock from a Cypress CY22393 programmable clock, which itself is sourced from a crystal oscillator. CLK0 is fed back via a BUFG to the CLKFB pin. The DLL is configured to divide by 2 with duty cycle correction enabled, STARTUP_WAIT to false. The CLKDV output feeds the design via another BUFG. This configuration is basically identical to XAPP132 Fig 9, except the CLKDV output is used to drive the design. The DLL will lock successfully if an asynchronous reset is provided after power up or configuration. Without the reset the DLL remains unlocked. I have checked the supply to the chip after configuration and there is no apparent issue. I have connected the RST input of the DLL to ground and it never locks. I have tried enabling the STARTUP_WAIT and setting DONE to transition after lock, and it never finishes the start-up process. I have removed all of the logic in the design, except the DLL, and it locks every time after power up, configuration or reset. Could there be something in the logic stopping the DLL from locking? Thanks in advance RichArticle: 51584
A problem: Pretty much by definition in an adaptive filter, you don't know *where* in the 10 taps the non-zero elements and coefficients will appear! You don't know in advance which elements or which coefficients will be null at any given time. You actually do need one multiply per tap and, usually, one multiply per coefficient update...though the latter can sometimes be done with just shifts and adds...which is often slower... You didn't mention your data rates. If you are not doing high-speed video or multi-channel SONET channel equalization, and thus don't need a fully-parallel design, then don't worry about which points are zeros! For audio or low-speed video data-rates, a standard approach to this type of FPGA application might be something like the following: Use a single multiplier-accumulator element (MAC), and a state-machine, and loop through the 10 taps after each sample. Then loop again updating the coefficients. In a Xilinx Spartan IIE, for example, a ten-tap MAC loop takes 10 clocks plus a four clock MAC pipeline latency plus 3 clocks state-machine overhead per pass. (16-bit samples and coefficients). That's only 17 clocks total. Using a 50 MHz clock, two passes would only be 340 ns + 340ns per input sample. With two multipliers, you could both MAC the filter and update the coefficients in a single loop pass, cutting the processing time in half. "Dongho" <dhan@ecel.ufl.edu> wrote in message news:f6f40449.0301161156.291a8a6f@posting.google.com... > Suppose 10 tap adaptive FIR filter and there are lots of zeros in > input, say 2 out of 10. So I don't need 10 multipliers to muliply 10 > inputs and coefs because of many zero inputs(I need 2 multipliers). > After calculating sum of inner product I need to update the coefs. > How to save multipliers to implement adaptive FIR for this case? > ThanksArticle: 51585
Assaf Sarfati wrote:
> 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:
I cannot resist (as designer of the IDaSS tool) to counter your remarks ;-)
Just to indicate that (IMNSHO) good schematic tools which stop at the right
point with using schematics are a good alternative to HDL's. Feel free to
comment, of course - I can take criticism :-)
I put a link to the IDaSS homepage at the end ;-)
> * Schematics can make the design structure and data flow more
> visible? sure, if your design flows data from one end to another.
Yep - good practice in drawing schematics.
> 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!).
In IDaSS, clock and reset are implied, no need to draw them. Also,
control and test signals from/to FSM's are not drawn but connected
by name from within the FSM description. You only see data buses and
RTL level blocks (which include the FSM's and sub-schematics) on the
schematics.
> * 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.
In IDaSS, you use a comment window to attach comments to blocks,
individual connectors, data buses, complete schematics etc. Comments
are also placed in all textual descriptions (FSM states, combinatorial
logic functions, data-to-control signal decoders etc.).
> * 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?
In IDaSS, yes. If you tell a register block to increment or decrement,
it is a counter. This can be done continuously, under control of an
FSM (or more FSM's, as long as they don't send conflicting commands) or
controlled by decoding values on a databus.
> * 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;
As I indicated, a counter or an FSM or an ALU can be one block in IDaSS,
a few words of comments like 'counts between 5 and 27' suffice here.
> 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.
With that last statement, I have to disagree completely - I'm not allowed
to show you a piece of Verilog which even the original designer does not
understand anymore (so they asked me to do a review - I've started drawing
schematics). Undocumented HDL is a capital offence.
> * 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.
If the HDL writers took care to keep signal names consistent, following
them can be done. It is not easy, though, when working on a multi-million
gate VLSI (described with several hundred HDL files).
For IDaSS, I've chosen very early on *not* to represent FSM's graphically.
Instead, I use a specially tailored language which directly names the
blocks to test and control and uses readable names for the commands to
send to the blocks. State transitions are also easily spotted and the
states themselves are named.
> * 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.
I have to agree - IDaSS is lacking version control. Is on the to-do list...
In our design team at work (where we use 'raw' Verilog, not IDaSS :-( ),
we *have* to use a version management tool - we would be absolutely lost
without it.
> * Simulation & verification: if your design is a schematic, how do you
> simulate?
Hah - that is probably IDaSS's strongest point: the simulator is integrated
with the 'design entry' tool. The 'SUD' ('System Under Design') is being
simulated while it is built. The schematics are alive, and you have access
to the state (and not only for inspection, also for changing it) at all
times. You can clock step the simulation, change values in registers and see
results of combinatorial logic immediately change, run for a specific
simulation time or number of clocks...
> 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)
The 'I' in IDaSS stands for Interactive - and the interaction is indeed
with the user (although you can easily create 'old fashioned' test
benches if you want, there is even a special block which allows you
to write test programs for execution in connection with the RTL design -
more than one of these blocks can be used, they allow interrupts to be
modelled, etc. etc.).
> and automate the whole process; run it at night
> and in the morning you see, before your first coffee, if it worked or
> not.
Yup - and then you may have to dig into millions of clock cycles of data
to find where it went wrong - ooops, did not log that signal :-(
I know that drill and I have to live with it... Regression testing
has its merits and must be done - should be first time right, though.
> 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.
I absolutely, completely agree - I taught at University, and made sure
the students could write assembly as well as 'high level' C (oh, and
they designed working microprocessors with IDaSS in their first year).
OK, the promised link to the 'Interactive Design and Simulation System'
(IDaSS) homepage:
http://www.xs4all.nl/~averschu/idass
Greetings and have fun,
Ad Verschueren
Article: 51586David, Virtex was never supported in WebPACK. The first Virtex family supported in the WebPACK was VirtexE. You will need to purchase ISE BaseX to do a XCV50. Steve Langmann wrote: > Hi, > > I was under the impression (from a previous post) that support would be > available for older devices (such as the XCV50PQ240, for example) in the > free or low cost software that Xilinx provides on the Web. From what I see > in ISE 5.1 this is not the case. > > Does anyone have any information on this? > > Thanks, > DavidArticle: 51587
> While a design spread over multiple chips are much harder to simulate, > it might be cheaper to do a board with everything in one chip. > > Rene I would rather use a single device. But there are many reasons which make that difficult. The design size is not small enough to meet the timing requirement and fit in a single device as of now. Also, two different companies could be working on the project with neither wanting to give out IP (for good reasons). In such a situation, multiple boards are inevitable. Also one of the boards may have an ASIC on it. Thanks, PrashantArticle: 51588
Steve, Since Virtex-E up to 300K system gates is supported by ISE WebPACK, why not Xilinx support Virtex up to 300K system gates in ISE WebPACK? Kevin Brace (If someone wants to respond to what I wrote, I prefer if you will do so within the newsgroup.) Steve Lass wrote: > > David, > > Virtex was never supported in WebPACK. The first Virtex family supported > in the WebPACK was VirtexE. You will need to purchase ISE BaseX to do > a XCV50. > > Steve >Article: 51589
In article <b07ej5$d5t$1@newsreader.mailgate.org>, Kevin Brace <kev3inbrac5eusen7et@ho9tmail.c1om> wrote: >Steve, > >Since Virtex-E up to 300K system gates is supported by ISE WebPACK, why >not Xilinx support Virtex up to 300K system gates in ISE WebPACK? I thought Spartan II was in many ways compatable with the Virtex? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51590
I wrote: > Have you seen such a manual for a C compiler? "Austin Franklin" <austin@da98rkroom.com> writes: > Er, yes. Where?Article: 51591
"David" <gretzteam@hotmail.com> wrote in message news:<gVlT9.10113$3u5.32039@weber.videotron.net>... > Hi, > 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 what's the fun in buying a kit :)? The following board is inspired by the XESS XCS series board, and uses an XC4000 part. http://www.geocities.com/wv9557/fpga_pic.jpgArticle: 51592
My last attempt at getting Altera support wound up with their answering me with blanks. That's right, BLANK responses. And I don't believe they read the messages either, based on previous answers. I have turned to Xilinx now, and must say that their (free) web-based software and readily available parts (Digikey) beats Altera hands down. Not to mention that I have seen Xilinx's presence on this newsgroup! If Altera is here, they are well-hidden. On Mon, 13 Jan 2003 14:20:04 +0100, "Matjaz Finc" <matjaz.finc@fe.uni-lj.si> wrote: >My experience: > >The Altera MySupport is useless, often slow and above all inapropriate in my >experience. Looks like it's there just for marketing purposes - to be >mentioned as superb on-line support for potential customers. When you (me) >need help, usualy you get riduculous short answers that show they don't even >try to read your whole message, not to mention answering it thoroughly and >exactly. I often find the solution to my problems in this newsgroup (really >prompt response!) or on my own before I get any info from MySupport that >makes any sense. > >Regards, >Matjaz > >"Austin Lesea" <austin.lesea@xilinx.com> wrote in message >news:3E1C4F1E.1BD53CBD@xilinx.com... >> Rene, >> >> Please, do not discourage people from using internet based support tools. >> >> I can not speak for Altera (obviously), but email and web-based support is >> becoming a major means of asking and answering customer questions in a >timely >> fashion. >> >> The fact that Altera has someone who watches the comp.arch.fpga forum >indicates >> that they really do care about customer service, and 'caught' your inquiry >in this >> forum. >> >> Our hotline group would prefer that a case gets entered into their system, >as they >> will answer it quicker that way. But for those that wish to get other >opinions, >> this newsgroup is also valuable. >> >> I know that Xilinx takes this all very seriously, and watches response >time vs. >> how the case is entered to maintain quality of service target levels. >> >> >> >> Austin >> >> Rene Tschaggelar wrote: >> >> > Thanks for the quick reply. >> > Amazingly quicker than the mentioned 'MySupport', >> > but then again not - proves my point. >> > >> > Rene >> > >> > Subroto Datta wrote: >> > > Rene, >> > > A fix for this problem is under development. More details about its >> > > availability will be posted as soon as the fix is tested and released >in the >> > > very near future (no later than end of this week). Thanks for bringing >this >> > > problem to our attention. >> > > >> > > - Subroto Datta >> > > Altera Corporation >> > > >> > > "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message >> > > news:3E1B4021.2090607@dplanet.ch... >> > > >> > >>I found a bug in quartus2 Web V2.2. >> > >>When tring to place legacy components in schematic editor, >> > >>such as the 74165b shiftregister, its connectors are off >> > >>grid. This makes it somewhat hard to connect. >> > >> >> > >>Did anyone figure a workaround ? >> > >> >> > >>Their support is useless : login(!), place a question, >> > >>relogin(!) to get a reply, so I didn't ask there. >> >Article: 51593
I think I disagree with you here. One shouldn't need to flatten the hierarchy for
debug nor for placement. For placement, RLOCs are hierarchical...use them for
hierarchical floorplanning. We do this, and typically only spend a day or two on
some quite extensively floorplanned designs. I really ought to put a floorplan
gallery on my website to point out what I am talking about. If you've ever seen
one of my design floorplans you'd immediately recognize that it is far different
that what you usually see in floorplans. Hierarchy in the floorplanning saves
gobs of time (I shudder to think how long it would have taken to floorplan a
recent full XC2V6000 design if it wasn't done hierarchically. With hierarchy, I
spent less than 20 hours in floorplanning including the time to put hte RLOCs in
the code (the lower levels of the code were already RLOCed and are reused
code). For debug, I generally use lots of simulation and a little bit of extra
hooks added to the design. Again, I couldn't imagine trying to wade through a
flattened design in that scenario.
Frankly, I'm not sure how size swamps hierarchy. In fact, I think the larger the
design the more necessary hierarchy is to keep the design problem sane. Hierarchy
lets you divide and conquer in the design as well as in the verification.
"Keith R. Williams" wrote:
> Hierarchy only goes so far. Sheer size can swamp the best thought out
> hierarchy. Eventually you need to flatten the hierarchy (placement,
> debug, etc.). These things caught us many years ago, which is why VHDL
> was chosen, I suspect.
>
--
--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: 51594Gentlemen: I used ABEL from "Digital I/O" (made available to educational institutions at reduced cost). I found out the cost of this software to noneducational institutions is a couple of hundred percent more than what the college paid for it. I used the PLDs made available to the students (18CV8s). The reason I was originally interested in this has to do with RadHard FPGAs that can be programmed to be CPUs as well as producing a more minimized design of the board I had been working on. Anyway, this all has some relevance to space applications and Minimal Instruction Set Computers (apparently the next generation of CPUs will be designed to minimize the number of transistors without compromising performance). Thanks for the input, 2Penny rickman wrote: > 2Penny wrote: > >>Gentlement: >> >>I've built a small computer board for a small local college (mostly >>from one of the professor's designs and partly from designs in the >>book). The machine uses PLDs in several places and I figured I could >>simplify the board some (and improve by skills) by (learning about and) >>using FPGAs, but I don't know where to get the initial software or >>download equipment. > > > If you want to simplify the board, you might do better using a CPLD. > FPGAs can be used, but they are not ready for operation at power up. > They must be configured. Most of the CPLDs are EEPROM or Flash based > and once programmed, will operate immediately on power up. The CPLDs > are mostly organized as multiple PLDs with extra interconnections. Can > you tell us what PLDs the board currently uses? >Article: 51595
Hi Kuan, When you add a pin in Xilinx FPGA Editor it asks for a name in a field called "component name". There by default it is "$Comp0". You can edit the name and give it another one but be sure to add the "$" sign. Regards Amit Ashara Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030116102633.19960B-100000@vcmr-86.server.rpi.edu>... > Hi, > I have solved it.But the strange thing is: when I add a pin named A1 in > the schematic design,the pin is not shown as A1 in the FPGA editor.The > name is changed to xlxn_2 or something similar.Do you have any way to > solve it? > > Thank you very much! > > sincerely > ------------- > Kuan Zhou > ECSE department > > > On 16 Jan 2003, Amit wrote: > > > 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 department > > > >Article: 51596
"Austin Franklin" <austin@da98rkroom.com> wrote in message news:<v2dvkemrfapa1b@corp.supernews.com>... > > SW engineers ...SW engineers ....SW engineers .... > > You are making a GROSS assumption here, that people who write software ARE > in fact engineers. Most are simply NOT. In fact, I would say very few are. > > Austin I was being respectful here, at least I would say so for most of the SW engineers at the famous EDA companies. As for the mass of folks that write in VB or any other script langs, well I don't usually come across them.Article: 51597
Hi All, I Agree with Falk Brunner's suggestion of routing the clock from a normal I/O pin to a IBUF and BUFG so that it can take the global routing resource. But do not try to put an IBUFG as it will be locked to a clock pad. Also to stabilise the clock try using a DLL or a DCM alongwith it. In this case the clock to the internal logic will be a very stable clock. Regards, Amit "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b06vfj$mcpnb$1@ID-84877.news.dfncis.de>... > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > news:3E26F6D3.18D62D71@yahoo.com... > > Agree. > > A clock should only be routed on a global clock net. Yes, you can also use > local routing, but this is the high art for the guys that know what they are > doing. > But In this case, the is a possibility to workaround this problem. > Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer). > This way, you can get your clock signal into you FPGA via a normal IO pin > and route it internaly to the global clock buffer. The only thing you will > not ave compared to the dedicated clock input is, the defined timing > relation between the clock on the input pin and the clock on your global > clock net, means, the skew between them is more of less random within some > limits. But this wont be a problem if you have no control line comming into > you FPGA with a fixed timing relation to your clock.Article: 51598
I concur with bringing the clock to a bufg (not an ibufg) once it is in the chip. The DLL won't clean up
a clock with jitter, the best it will do is restore symmetry to the duty cycle. If you have external
signals also sync'ed to the clock, you are in for a possibly rough ride for sampling those signals as the
clock skew is no longer tightly controlled. If you had a clock out from the FPGA you could use that with
a DLL to clean up the clock timing, but then you'd be back in the same situation of having to respin the
board.
Amit wrote:
> Hi All,
>
> I Agree with Falk Brunner's suggestion of routing the clock from a
> normal I/O pin to a IBUF and BUFG so that it can take the global
> routing resource. But do not try to put an IBUFG as it will be locked
> to a clock pad. Also to stabilise the clock try using a DLL or a DCM
> alongwith it. In this case the clock to the internal logic will be a
> very stable clock.
>
> Regards,
> Amit
>
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<b06vfj$mcpnb$1@ID-84877.news.dfncis.de>...
> > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> > news:3E26F6D3.18D62D71@yahoo.com...
> >
> > Agree.
> >
> > A clock should only be routed on a global clock net. Yes, you can also use
> > local routing, but this is the high art for the guys that know what they are
> > doing.
> > But In this case, the is a possibility to workaround this problem.
> > Instanciate a IBUF (normal input buffer) and a BUFG (global clock buffer).
> > This way, you can get your clock signal into you FPGA via a normal IO pin
> > and route it internaly to the global clock buffer. The only thing you will
> > not ave compared to the dedicated clock input is, the defined timing
> > relation between the clock on the input pin and the clock on your global
> > clock net, means, the skew between them is more of less random within some
> > limits. But this wont be a problem if you have no control line comming into
> > you FPGA with a fixed timing relation to your clock.
--
--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: 51599Matt wrote: > > This seems to be a hint to my answer. I'll rephrase the question. There > are companies that sell software that will take matlab or Handel-C and > turn it into fpgas. So fft->fpga is possible. What I want to do is > quantify how good that might be. There's another thread running about > schematic entry vs vhdl that implies that vhdl is ok if it's used to > describe data flow as opposed to serial process flow. This implies that > the serial->data flow translation is not so good. How bad is it? If > writing serial code generates an fpga that's half as fast as writing > data flow then that's not bad. If it's a 1000 times slower and is 10 > times the size then that's a serious problem. It's the usual assembly vs > C tradeoff. > > Assuming the program is written using data flow, can a compiler do a > good job of place and route or is this another case where the user has > to get involved? Considering that the graph theory anywhere near this > type of stuff is all NP I assume there is a problem. Since there are > tools that allow people to help with this I'm sure there's a loss of > efficiency by just letting the tool do everything. I just want to know > how much of a loss there is. I have never worked with Handel-C before. But in VHDL and Verilog you need the concept of concurrency in order to describe hardware. Conventional C programs are not normally written in this style and so do not translate into hardware well or possibly at all. I know that Handel-C is not the same as conventional C. If it were they would just use that. I guess my question to you is, was the FFT written in C or Handel-C? If you know of vendors who sell these tools, then you should be asking them to show you some examples of code and how well it translates into hardware. Then ask them about your application. If you can provide code to them, they should be willing to run it through the tools for you as a sales demo. They might even be able to demo the result on an FPGA eval board. An FFT really doesn't require lots of hardware. But it depends entirely on how it is implemented (as specified in the code) which is what HDLs are all about. -- 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 FAX
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