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
Austin Franklin wrote > Tim wrote > > I can see how you can mimic the functionality of a schematic > > in a programming language. But the other way round seems tough. > > Hi Tim, > > If I understand what you mean...I can tell you that I USED to get a LOT of > jobs doing exactly that...taking VHDL and converting it to schematics. Austin Absolutely correct. But usually you are concerned with optimizing the data flow, and you can convert the data flow to a structural representation within VHDL. In fact the LUT stuffing code on my site at www.rockylogic.com/freebies/freebies.html "Locking Logic to a Single Xilinx Virtex LUT" is an example of how to do this in VHDL at a _very_ low level. Probably a lower level than is of interest to most users, and equivalent to the lowest level possible with schematic. A great advantage of using an HDL is that everything can be parameterized, with arbitrary calculations of the parameters at instantiation time. And everything can be replicated N times over, with just a simple loop statement. It may be possible to do this with some schematic packages, but I only have substantial experience of the OrCAD product. And even there I retreated to the old 16-bit DOS product when I discovered how unfriendly the later stuff had become. I think your comments have more force when you compare schematic to Verilog - I don't think that even Phil Moorby would see standard Verilog as the last word on the subject. The lack of decent parameter manipulation, a generate loop, and arbitrary attributes mean that everyday Verilog engineers have to be good at modifying netlists via Perl scripts, TCL scripts, UCF files, or whatever. Of course, given that FPGA design is harder than ASIC design, these problems hit us while the ASIC mob is still using brute force.Article: 51551
This used to be ok until I reloaded the design on another PC, but now I am getting the following error under P&R using: V4.1i of Xilinx ISE "ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad signal=VCO_70MZ) or BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG should only be LOCed to GCLKIOB site." In my design I haven't specified that VCO_70MZ should be through a BUFG. I am using HDL designer and Leospec for my source code. 1. Where does ISE get the assumption that this is through a clock buffer? 2. How do I fix it without changing the LOC.?Article: 51552
In cases where you really care what is synthesized...ie you know the logic you
wish to create, the safest way is to structually instantiate that portion of you
design. I do it rather extensively on our high performace designs. It isn't
hard to do, but it does take a bit of time to build your libraries to a point
where you can do it rapidly.
Eric Smith wrote:
> "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.
--
--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: 51554Jock wrote: > > This used to be ok until I reloaded the design on another PC, but now I am > getting the following error under P&R using: V4.1i of Xilinx ISE > > "ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad signal=VCO_70MZ) > or BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG > should only be LOCed to GCLKIOB site." > > In my design I haven't specified that VCO_70MZ should be through a BUFG. I > am using HDL designer and Leospec for my source code. > > 1. Where does ISE get the assumption that this is through a clock buffer? > 2. How do I fix it without changing the LOC.? Hi LeoSpec automatically inserted the IBUFG because this signal must be used as a clock in your design. Just disable the "Add clock buffer" option in LeoSpec and resynthesize your design. Anyway, using a GCLKIOB site for your clock input would be a good idea... NicolasArticle: 51555
How far can I go to implement a 3D vertex processing pipeline on a 200K gates fpga?Article: 51556
Hello,
Kuan Zhou <zhouk@rpi.edu> writes:
> 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?
no, the LUTs can still have only 4 inputs if in LUT-mode
(G1-G4). G1-G4 are used if the LUT is in RAM-mode, e.g. if in
dual-port configuration the G1-G4 are read address inputs and the
WG1-WG4 are the write address inputs.
Flolo
--
int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u)
["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&&
I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
Article: 51557I just want to make a small demonstration, there is no input( no API interface), vertex data are generated in the fpga, and there will be a small texture defined as rom in the fpga. I'm using the RC100 board with HandleC. Celoxica has a floating point library for HandleC which I'm using. Thanks "tsao" <feng_1955@no_spam_ybb.ne.jp> wrote in message news:b06cvm$21nr$2@news.ecc.u-tokyo.ac.jp... > How far can I go to implement a 3D vertex processing > pipeline on a 200K gates fpga? >Article: 51558
On Thu, 16 Jan 2003 00:04:39 -0500, "Austin Franklin" <austin@da98rkroom.com> wrote: > >"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. [...] > >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. > I suspect that would only be possible for a primitive (probably highly inefficient) synthesis process. Leo Spectrum can run four passes on each block, with widely differing area (LUT count) and speeds - often about 2:1 in each - and it picks the best (smallest or fastest, you decide) before moving onto the next block. Block, here, means either the whole design, or each entity, or some level in between - again, you choose in a number of ways. Given a regular, highly ordered (or simply small) block, each pass converges to exactly the same speed and area - and presumably internal structure - but for larger blocks, the variation observed above is seen. My conclusion from this is that for very simple designs its behaviour can be documented as you ask, but that for larger blocks it is capable of selecting from so many different strategies and performing so many optimisations and transformations that no such prediction is possible. I haven't often viewed the resulting code, but have sometimes been impressed at how devious/cunning/clever it can be in finding e.g. optimisations between block boundaries (when I let it auto-dissolve or flatten the hierarchy) ... and only occasionally appalled at how stupid! - BrianArticle: 51559
Hi, In the Virtex - II Pro Architecture the WG1 to WG4 are write address inputs when the LUT is used as a dual port RAM. The function of read address inputs is provided by A1 to A4. If you will notice that besides WG1 to WG4, WF1 to WF4 also provide the same functionality. Regards, Amit Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030116003702.14675B-100000@vcmr-86.server.rpi.edu>... > 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: 51560
"Nicolas Matringe" <nicolas.matringe@ipricot.com> wrote in message news:3E26B10E.94E42CF8@ipricot.com... > Jock wrote: > > > > This used to be ok until I reloaded the design on another PC, but now I am > > getting the following error under P&R using: V4.1i of Xilinx ISE > > > > "ERROR:MapLib:93 - Illegal LOC on symbol "VCO_70MZ" (pad signal=VCO_70MZ) > > or BUFGP symbol "VCO_70MZ_ibuf" (output signal=VCO_70MZ_int), IPAD-IBUFG > > should only be LOCed to GCLKIOB site." > > > > In my design I haven't specified that VCO_70MZ should be through a BUFG. I > > am using HDL designer and Leospec for my source code. > > > > 1. Where does ISE get the assumption that this is through a clock buffer? > > 2. How do I fix it without changing the LOC.? > > Hi > LeoSpec automatically inserted the IBUFG because this signal must be used as a > clock in your design. Just disable the "Add clock buffer" option in LeoSpec and > resynthesize your design. > Anyway, using a GCLKIOB site for your clock input would be a good idea... > > Nicolas I agree, but as the PCBs are already laid out, I'm not allowed to change the Pins. Anyway I disabled the "add clock buffer" (set insert_global_bufs FALSE in TCL-talk) but I'm still getting the same error, so now I'm rather baffled.Article: 51561
This isn't the answer you want, but since you can implement a C programmable
soft core in 10-20% of a 200K gate FPGA, you can run several software
rendering pipelines in parallel in such a device.
Or you can use one soft processor to absorb all the setup and management
aspects of the renderer and use the remaining 80-90% of the FPGA for the
rendering pipeline.
(I don't know whether (or if not, why not) synthesis tools (like Celoxica)
could exploit a soft processor core for absorbing RELATIVELY lower speed
setup and management code, but it seems to me a good idea -- sometimes in
the lower-performance-requirement parts of a design, it is profitable to
trade off speed for area (trade a soft CPU core and instructions in a block
RAM to save a sea of raw random logic gates. That way, every HLL design
would fit in an XC2S50 plus external RAM -- and then if you specify an FPGA
10X or 100X larger the synthesizer could "automatically" move more and more
of the inner loop datapaths into gates.)
I don't know about the Celoxica FP library, but traditionally FP is
expensive in FPGAs (http://www.fpgacpu.org/usenet/fp.html).
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
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.
Jan Gray, Gray Research LLC
Article: 51562
Depends on how clever you get with the design, and at what
speed you need to operate. First suggestion would be to
look at fixed point, and be very careful about how you
describe the design in Celoxica or you may find it very
difficult to get into a 200K marketing gate part.
tsao wrote:
> I just want to make a small demonstration, there is no
> input( no API interface), vertex data are generated
> in the fpga, and there will be a small texture defined
> as rom in the fpga.
>
> I'm using the RC100 board with HandleC. Celoxica has a
> floating point library for HandleC which I'm using.
>
> Thanks
>
> "tsao" <feng_1955@no_spam_ybb.ne.jp> wrote in message
> news:b06cvm$21nr$2@news.ecc.u-tokyo.ac.jp...
> > How far can I go to implement a 3D vertex processing
> > pipeline on a 200K gates fpga?
> >
--
--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: 51563Hi, 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: 51564
On Thu, 16 Jan 2003 14:40:54 +0530, "Skillwood" <skillwoodNOSPAM@hotmail.com> wrote: >Hi, >Is there any free HSPICE simulator available in the Web? > >Thanks >Skillie > There are many free SPICE simulators available but HSPICE is a commercial, rather expensive implementation of SPICE. You may want to check out this link http://www.repairfaq.org/ELE/F_Free_Spice.html Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 51565
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. "Jan Gray" <jsgray@acm.org> wrote in message news:b06hf4$she$1@slb2.atl.mindspring.net... > This isn't the answer you want, but since you can implement a C programmable > soft core in 10-20% of a 200K gate FPGA, you can run several software > rendering pipelines in parallel in such a device. I'm writing a Hardware rendering pipeline including transform&lighting, texture mapping. Most of the operation is done in floating point. There will be like 20+ floating point multipliers in one pipeline. > Or you can use one soft processor to absorb all the setup and management > aspects of the renderer and use the remaining 80-90% of the FPGA for the > rendering pipeline. > > (I don't know whether (or if not, why not) synthesis tools (like Celoxica) > could exploit a soft processor core for absorbing RELATIVELY lower speed > setup and management code, but it seems to me a good idea -- sometimes in > the lower-performance-requirement parts of a design, it is profitable to > trade off speed for area (trade a soft CPU core and instructions in a block > RAM to save a sea of raw random logic gates. That way, every HLL design > would fit in an XC2S50 plus external RAM -- and then if you specify an FPGA > 10X or 100X larger the synthesizer could "automatically" move more and more > of the inner loop datapaths into gates.) > > I don't know about the Celoxica FP library, but traditionally FP is > expensive in FPGAs (http://www.fpgacpu.org/usenet/fp.html). Will it be less expensive with soft core? How much? > 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. > 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. > > Jan Gray, Gray Research LLC > >Article: 51566
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 ? Hoping to receive advice soon. Thanks, PrashantArticle: 51567
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: 51568
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qhd6mxoc6p.fsf@ruckus.brouhaha.com... > "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. And that can be a problem. Not only that, but if you change one minor thing, or have a rev change of the tools, it can screw up what used to work fine... > and would almost always be out of date. Not if it was adhered to. > Have you seen such a manual for a C compiler? Er, yes. > 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. That's not engineering, it's guessing. I am not into "guess what the synthesis tool is going to do now", it's a waste of time. AustinArticle: 51569
Matt wrote: > > 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? > > Matt Sounds to me like you are a software person rather than a hardware designer, 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. -- 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: 51570
Jock wrote: > > I agree, but as the PCBs are already laid out, I'm not allowed to change the > Pins. > Anyway I disabled the "add clock buffer" (set insert_global_bufs FALSE in > TCL-talk) but I'm still getting the same error, so now I'm rather baffled. Maybe I don't understand the issue correctly. Are you saying that you have a clock signal in your design that drives the clock inputs on FFs, but you don't want to run it through the global clock buffer because someone has given you a pinout that puts the clock on a different pin? This is not a good situation. If you don't use the global clock routing it will use the general routing. You can, and most likely will, have problems with clock skew where a signal that is changing because of the clock will reach another FF before the clock does so that the FF will latch the wrong value. I don't know why you are constrained to this pinout, but you should think very hard about using a global clock buffer. Unless this clock drives a very small section of the FPGA, I don't think I would try to use general routing for a clock. -- 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: 51571
In article <qhd6mxoc6p.fsf@ruckus.brouhaha.com>, Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: >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. Yet also far less important. C is inherantly sequential semantics, and if you just do a literal translation you actually end up being OK-good-enough on a modern processor. EG, compare lcc (VERY simple and dumb) vs gcc -04, and although gcc wins significantly, it's not a MASSIVE difference. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 51572
> 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. AustinArticle: 51573
"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. -- MfG FalkArticle: 51574
In article <v2dvkemrfapa1b@corp.supernews.com>, Austin Franklin <austin@da98rkroom.com> wrote: >> 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. "If builders build buildings the way programmers write code, the first woodpecker to come along would destroy civilization" -- Nicholas C. Weaver nweaver@cs.berkeley.edu
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