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
If anyone is looking for a Spartan 3 board for hobbyists and students, that also includes a solderless breadboard for adding your own circuitry, have a look at www.dulseelectronics.com . An article about the board appeared in the Dec 2004 issue of Circuit Cellar Magazine. Phil Dulse ElectronicsArticle: 77426
"Stefan Duenser" wrote
> Hi all
>
> I have implemented a very easy memory with a few registers, where i can
> store and also read values for and from my ALU:
>
> I have got 2 questions:
>
> 1) The conv_integer procedure does not work here, I always get the
> errormessage: no feasable subprogram entry for conv_integer. Any ideas whats
> wrong here?
On this one, comp.lang.vhdl is the place for the VHDL questions.
If you check the archive you will see a zillion repetitions of
this advice: use the numeric_std library
Then you can use to_integer().
I usually use an indirect function to clean up the simulation:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.numeric_std.all;
function ToInteger(ARG: UNSIGNED) return INTEGER is
variable x: unsigned(ARG'range);
variable n: integer;
begin
x := ARG;
-- synthesis translate_off
for i in x'range loop
if x(i)/='1' then -- resolve the 'undefined' signals
x(i) := '0';
end if;
end loop;
-- synthesis translate_on
n := to_integer(x);
return n;
end;
Article: 77427> 1) The conv_integer procedure does not work here, I always get the > errormessage: no feasable subprogram entry for conv_integer. Any ideas > whats wrong here? I really dont understand why this is not working, because this functions are declared in the ieee.std_logic_arith.all header... FUNCTION to_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 ) RETURN INTEGER; FUNCTION to_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 ) RETURN INTEGER; FUNCTION to_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN NATURAL; FUNCTION to_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN NATURAL; FUNCTION to_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER; FUNCTION conv_integer ( arg1 : STD_ULOGIC_VECTOR; x : INTEGER := 0 ) RETURN INTEGER; FUNCTION conv_integer ( arg1 : STD_LOGIC_VECTOR; x : INTEGER := 0 ) RETURN INTEGER; FUNCTION conv_integer ( arg1 : STD_LOGIC; x : INTEGER := 0 ) RETURN NATURAL; FUNCTION conv_integer ( arg1 : UNSIGNED; x : INTEGER := 0 ) RETURN NATURAL; FUNCTION conv_integer ( arg1 : SIGNED; x : INTEGER := 0 ) RETURN INTEGER any useful tips?Article: 77428
The xil_printf documentation states:
This function is similar to printf but much smaller in size (only 1KB). It
does not have support for floating point numbers. xil_printf also does not
support printing of long long (i.e 64 bit numbers"This func is similar to
printf but much smaller. It does not have support for floating pt numbers or
long long. "
Try using %d instead of %l and see if you get *something*...
"Patrick" <mai99drh@studserv.uni-leipzig.de> wrote in message
news:9bb2b1a1.0501060813.78b7a669@posting.google.com...
> Hello,
>
> i know this is a rather stupid question, but i'm somewhat irritated.
>
> I'm triing to send some data per Uartlite. For normal
> characters/strings everything works fine, but if i try to send some
> integers or long integers they aren't displayed.
>
> (Short) example:
>
> ...
>
> /* global definitions, no pointers */
> Xuint32 interrupt_count = 0;
> volatile Xuint32 jiffies = 0;
>
> ...
>
> /* values incrementd during pit-isr, pit works, pit running at 100HZ
> */
> void pit_timer_int_handler(void * baseaddr_p)
> {
> jiffies++;
> interrupt_count++;
>
> XTime_TSRClearStatusBits(XREG_TSR_PIT_INTERRUPT_STATUS);
> }
>
> ...
>
> main(){
>
> /* string displayed correctly */
> xil_printf("\r\nRunning Mainloop");
>
> while(1){
> sleep(2);
> xil_printf("\nLoop");
>
> /* here the values aren't displayed,but the "a"s and "b"s are displayd
> */
> xil_printf("\n %l a", i_interrupt_count);
> xil_printf("\n %l b", l_interrupt_count);
> /* giving the arguments as pointers won't help either */
> xil_printf("\n %l a", &i_interrupt_count);
> xil_printf("\n %l b", &l_interrupt_count);
> }
>
> }
>
>
> i have tried different compinations with "%d","%D","%l","%ul" or "%c"
> as format-strings and different datatypes for the two variables
> (unisgned, int, long, unsigned long).
>
> i was looking at the xil_printf sources, too, to see what characters
> after "%" are supported.
>
> I'm using an uartlite at 9600 baud, 8 databits, no parity.
>
> So, does someone might have an idea or hint what my mistake is?
>
> Regards
> Patrick
Article: 77429Our experience has been about 70-80%. Interestingly, on large parts you can have trouble if you aren't using enough resources because the tools 'spread' the logic across the chip too far and cause timing errors. So... ideally? I would say 60-80% utilization. "Rudolf Usselmann" <russelmann@hotmail.com> wrote in message news:crjn5n$1d4$1@nobel.pacific.net.sg... > stockton wrote: > >> Dear All, >> >> I hope that you can help. >> >> I am looking at trying to fit a number of IP cores into a single >> Xilinx FPGA, I have heard that it is not possible to completly utilise >> all the FPGA resources (RAM, Logic Cells, DCMs etc ... ) because of >> routing problems. >> >> Do anyone know of a rough percentage of the the FPGA resources that >> can be expected to be utilised before issues arise in trying to route >> the design? >> >> I have head that it is as low as 60% but am hoping that this is not >> the case. >> >> I understand that it really does depend on what you put into the FPGA >> but to only be able to utilise 60% on average seams a little poor to >> me. >> >> Kind Regards >> >> Simon > > We test all of our IP Cores on a few Xilinx Development > boards we have in house and are stuck with device sizes. > > We always have a small SoC that we attach our "Core to be > tested" to. I have seen utilization of 98%++ specially when > we make heavy use of ChipScope. As long as you stick with > EDK based SoC and their 100MHz bus speed limitation, you > are usually ok up 98% utilization. > > Best Regards, > rudi > ============================================================= > Rudolf Usselmann, ASICS World Services, http://www.asics.ws > Your Partner for IP Cores, Design, Verification and Synthesis >Article: 77430
"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> schrieb im Newsbeitrag news:41dd74ee$0$2457$ba620e4c@news.skynet.be... > Hi > > > Since we aren't talking drastic resolutions here, i figured they would > > be fast enough? > > I would guess so too ... 640x480 is < 30Mhz pixel clock, easily achievable. Yes, aka scan doubler. No big deal in a Spartan-II(E) or III Regards FalkArticle: 77431
On Thu, 6 Jan 2005 18:16:41 -0000, "Stefan Duenser" <carlsberg@gmx.at> wrote: >> 1) The conv_integer procedure does not work here, I always get the >> errormessage: no feasable subprogram entry for conv_integer. Any ideas >> whats wrong here? > >I really dont understand why this is not working, because this functions are >declared in the ieee.std_logic_arith.all header... [snip] Take heed of what the nice man said: USE NUMERIC_STD. Like many other people, you have unnecessarily included both use ieee.std_logic_arith.all; and use ieee.std_logic_unsigned.all; I think one of the Xilinx tools tends to add both these clauses by default - silly thing to do. Your problem is caused because CONV_INTEGER() is defined in BOTH packages. Consequently, neither definition is visible. You could, if you were desperate, use a fully-qualified function name: int <= ieee.std_logic_arith.conv_integer(vec); but that would be silly, wouldn't it? So PLEASE, get rid of std_logic_arith and std_logic_[un]signed from all your code, start using numeric_std instead, and read comp.lang.vhdl for lots of advice on how to do that. The quick fix is for you to remove one of the two use clauses, but it's way better to do it properly. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 77432
vadim wrote: > I have received a job offer from a company > in San Jose, California. The position title is: Test Development > Engineering. The salary offered is 67k/year with Relocation Assistance > and a Benefits package. I already have a 60k/year job in Toronto, > Canada as Applications Engineer. > > The San Jose job is closer to circuit-design which is an area I would > like to get into. > > I was told that the housing prices of Bay Area will make this salary > into a 50k equivalent of Toronto. So practically my "buying power" is > reduced. > > I have a dillema whether: > -Professional advantages of this position, closer to ciruit design. > -Working in Silicon Valley, the Mecca of HighTech. > > outweigh the offered salary ? > > Thanks in advance. I would guess you'd be financially better off in Toronto. I don't know how expensive Toronto is, but I know it will be fairly expensive to live in San Jose. And while the position may be closer to design, it's not terribly close. I'm surprised about the comments from the guy from Sweden. He must have moved someplace very expensive, because Sweden isn't cheap. And their tax rate is like 98%.Article: 77433
Hello all I need some introductory help with writing test bench cases for my VHDL code. I have written a lot of VHDL code, however I have always tested this using waveform simulation and then finally testing it on the product. I wish to go one step further by learning how to write test cases. Can someone give me a starting point to this pls? Is there a website that explains how to write test bench code? I am using Altera FPGAs and thus using Quartus II to write my VHDL code at present. Pls advice. Thank youArticle: 77434
Brian Drummond wrote: > On Wed, 05 Jan 2005 12:06:48 -0700, Bret Wade <bret.wade@xilinx.com> > wrote: > > >>Daniel wrote: >> >>>@Bret Thanks for the suggestion. Didnt know that its possible to fix the routing also within RPM macros. >>> >>>Are RPM macros usefull for design modules as large as my one (376 CLB Slices (752 FlipFlops, 260FG's), 8BRAMs and 1GlobalBuffer) or does this lead to problems with performance or even unstable workflows? > > > I am working with larger RPMs than this, with some degree of success > (cautiously expressed; the design is not yet complete) > > There *may* be problems with BRAMs and multipliers in RPMs. > There is a certain amount of complexity added when an RPM combines multiple component types (Heterogeneous RPM) due to the fact that for the default grid system, the various component types are on different grids. This is only a problem if your RPM requires normalization. If your RPM uses the X0Y0 slice and does not use any negative RLOC values, then no normalization occurs and there is not problem. If normalization is necessary, then the RPM must be implemented with the RPM Grid system. More on normalization and the RPM Grid here: http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf > >>Yes, large RPM macros can be used effectively. Multiple small RPMs can >>be assembled with offsets defined by hierarchical RLOCs to assemble a >>large RPM. Automatic placement of large RPMs can be a challenge so it >>may be necessary to locate the macro. I believe that Ray Andraka has >>posted on the subject of large RPMs in the past. You may want to Google >>for that. > > > There are problems using the floorplanner to create RPMs from smaller > ones, mostly associated with tools issues (the floorplanner alone has > two mutually incompatible understandings of RLOC_ORIGIN, the mapper > moves the origin left by 1 location under some (apparently undefined) > circumstances, the placer reports errors on some correct RLOC_ORIGIN > constraints and silently deletes others altogether, and so on. RLOC_ORIGIN values must take into account the normalization of the RPM. More on that in the appnote. The mapper converts RLOC_ORIGINs into MACRO LOCATE constraints in the PCF file, so strictly speaking it's not possible for the placer to ignore RLOC_ORIGIN constraints because it never sees them. A separate issue is that the RPM needs to be placed in the same "slice type" that it was created about. There are four slice types represented by the four slices in a CLB, S0-S3. For simplicitys sake, it is best to construct a macro about the X0Y0 slice and then always place it in an S0 slice type if possible. If the RPM is placed in a different slice type, the relative placement will be broken, which can lead to placement failures. I suspect that these two issues explain some of the behavior that you're seeing. I can't speak to what the Floorplanner is doing in constructing your RPMs. > > http://www.shapes.demon.co.uk/files/crashme.zip contains a test case for > a few of the problems, where only one of eight RPMs is placed correctly. > > There are other problems too, including floorplanner swapping BELs > within a CLB, and crashing when writing RPM UCF files. > > Maybe FPGA editor is a more stable tool for floorplanning? I would try > it but only have WebPack in current software. FPGA Editor is not a floorplanner. It is an editor for displaying and modifying the physical design and applying some physical constraints. The Floorplanner is an editor for applying constraints to the logical design. FPGA Editor is the only tool for applying Directed Routing constraints and it is useful for obtaining grid values for both the standard and RPM Grid systems. FPGA Editor is also a great tool for understanding the details of possible component, placement and routing configurations within the FPGA. > > But if you can identify and work round the tools limitations, it looks > tantalisingly close to workable, with RPMs considerably larger than > yours above, and composed hierarchically of RPMs several levels deep. > > One of the (undocumented? - at least I haven't found it anywhere) > workarounds seems to be to keep a component in the lower left hand > corner of the smallest bounding box that can surround the RPM, which > should site this corner at RLOC=X0Y0 - a condition violated deliberately > in the test case above (and accidentally in several of my RPMs!) This is the normalization issue again. You don't have to build the RPM around the X0Y0 slice, but if you don't, you have to account for normalization. > > Another is to "replace all with placement" (or "constrain from" as > appropriate) which corrects randomly swapped BEL elements, should they > occur. > > I would love to see some others, or an App Note on this process... > > And I'm hoping some of these floorplanner bugs can be fixed. > > >>>How fix is the routing "fixed" with directed routing in the later PAR of the whole design? Is it possible that the router changes anything? > > >>Since you mentioned that a large macro is involved, I should point out >>that Directed Routing is not recommended for use with large numbers of >>signals on the order of hundreds. Guide should be used instead. That >>recommendation depends on the nature of the routing involved and the >>level of congestion around the locked routing. > > > Guide is interesting, both because I don't have FPGA editor, and > apparently directed routing isn't intended for large RPMs. > > Can you point me in the direction of a flow that would use guided > routing for a top level module composed of several pre-routed RPM > modules? Preferably where at least one of the RPMs has itself been > created in this way? Directed Routing is not incompatible with the guided flows. There's no reason why you can't combine them. You'll just need to get FPGA Editor and try it. There is one problem area that I should mention. The placer can currently place an unconstrained slice in conflict with Directed Routing, where the locked routing blocks switchbox access to BX and BY pins on the slice. I've only seen it on one design so far that had a lot of Directed Routing that was using switchbox bank shots. Beware using routing constraints like that in areas where the slice utilization is uncontrolled. A work around is to prohibit the affected slice site. We're looking a placer fix in the 7.1i time frame. Regards, Bret > > I am currently finding it difficult to maintain timings achieved on > lower level modules when they are combined together, and scope for > routing congestion obviously increases. > > - BrianArticle: 77435
Tim, The case at issue was one where the hardened version was much faster. The much faster part was the IO itself was now much faster, and had less delay (a real issue when you are cutting out real estate to get the cost advantages - things get faster - it is unavoidable). So, speed (too slow) was not an issue. Speed (way too fast) was an issue. If the other part this one talked to was a FPGA, no problem, just reprogram the FPGA to accept that the signals were arriving a little ahead of where they used to. Too bad, they had already made that part an ASIC (from an ASIC vendor) just a few months earlier. Result, throw away all of the hardened parts, and go back to using the FPGA. Oh, and stick the vendor with the cost of failure as it was "guaranteed." It could be that this is what Paul is referring to: no cost of failure, as it will be paid for by the vendor until they get it right. Not my idea of a great business model, but hey, I don't like the whole hardened model anyway. Bottom line: If it ain't broke, don't fix it. An engineering maxim that was true years ago, and still true today. Change anything, and something will change (obvious, isn't it?). Will it be the IO timing? The IO signal integrity? The jitter performance? Will it be too fast? Will it be too slow (unlikely)? DOH! The ONLY solution that can make the claim of no pain, is ours: EASYPATH(tm). Why? Because we don't change anything at all. Same part, same silicon, same bitstream, just 30 to 50% (or more) cost savings. How could any person examining the costs of a product ignore EasyPath? Once the accounting folks (and CEO) understand the lack of risk, and the reduction in costs, an engineer's opinion (of goodness of badness) will not be worth a cent. The facts speak for themselves. Austin Tim wrote: > "Austin Lesea" wrote > > >>And, "seamless risk free" is just a plain an outright misrepresentation. >> >>I know of a customer that had a serious issue, and was unable to meet their >>production ship dates (fact). Only reason we know is that they had to >>continue buying the FPGA...... > > > Without taking sides on the underlying debate, is there a > possibility that problems and design practices masked by > the slower FPGA speeds come and bite at ASIC speed? > > Not everyone has read and followed the stuff on crossing > clock domains and so on. > > I'm just wondering how come fully debugged (!) designs can > go all bad. > >Article: 77436
Tried that, but i get this warning message: Started process "Generate Post-Place & Route Simulation Model". WARNING:Anno:255 - command line '-s -4' overrides .pcf TEMPERATURE = 70.000 C "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:345bivF47eeulU3@individual.net... > > "gja" <geeja@hotmail.com> schrieb im Newsbeitrag > news:SQdDd.3214$yK7.3065@fe11.lga... > > I want to do post place and route timing simulation on a Virtex2 part > using > > the Xilinx Modelsim starter simulator, how can I set the temperature point > > to 70 celcius? > > Add > > temperature=70C; > > to your UCF > > Regards > Falk > > > > >Article: 77437
If you do not constrain the timing, the tools "are lazy" and make their life easy, by spreading the logic around, so as to avoid congestion. The proper solution is to constrain the timing and thus force the tools to make more appropriate, more intelligent, and more demanding decisions. It's the tools' equivalent to Parkinson's Law: "Every job grows to use up all the available resources in time, space, and money". It's up to you to delineate the available resources ! Peter Alfke, Xilinx ApplicationsArticle: 77438
Hello: I'm entering a desing in to Altera's Quartus II 4.1 using block diagram files as the input mechanism. When I try to compile I get the following message...... Internal Error: Sub-system: CDB_SGATE, File: cdb_sgate_wys_ygr.cpp, Line: 4111 cdb_is_connected(b_iterm) Quartus II Version 4.1 Build 181 06/29/2004 SJ Full Version ............... The error is probably something I've done as I created the schematics. My question is how to track the error down? The design is heirarcail and I've tried deleting functional blocks. When I do I get different error messages because signals are now missing. What steps to take. Thanks GeorgeArticle: 77439
Yeah, no problem in current FPGA offerings. HDTV apps are far more
demanding in terms of pixel rate and image size, yet even spartanI
series parts were fast enough for HD apps with enough care taken on the
design.
Falk Brunner wrote:
>"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> schrieb im
>Newsbeitrag news:41dd74ee$0$2457$ba620e4c@news.skynet.be...
>
>
>>Hi
>>
>>
>>
>>>Since we aren't talking drastic resolutions here, i figured they would
>>>be fast enough?
>>>
>>>
>>I would guess so too ... 640x480 is < 30Mhz pixel clock, easily
>>
>>
>achievable.
>
>Yes, aka scan doubler. No big deal in a Spartan-II(E) or III
>
>Regards
>Falk
>
>
>
>
>
--
--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: 77440Looks interesting, but its a shame it does not have more 'standard' ports.. I realize you can wire them up yourself, but the more that are on board the less you have to dink around with.. Digiants boards look really good for development projects. Especially with the 400k upgrade option. Waiting on my to arrive. PNowe wrote: > If anyone is looking for a Spartan 3 board for hobbyists and students, that > also includes a solderless breadboard for adding your own circuitry, have a > look at www.dulseelectronics.com . An article about the board appeared in > the Dec 2004 issue of Circuit Cellar Magazine. > > Phil > Dulse Electronics > >Article: 77441
I eventually figured out what was wrong, so I'll post the solution in case anyone ever runs into the same problem. The problem was the windrvr.sys file in C:\WINNT\system32\drivers It was present, but it was an older version of the driver. A newer version was in the $XILINX\bin\nt directory and I copied it to the right place. Thanks very much to all who responded. -EwanArticle: 77442
Thanks Ray for your comment. How do you deduct from the error message the possibility of a gated reset ? and how could that be related to the addition of ICON and ILA cores ? that is the only "delta" from my "healthy" design ... RanArticle: 77443
A great vhdl online reference http://www.vhdl-online.de/~vhdl/Article: 77444
vbishtei@hotmail.com (vadim) writes: > I have received a job offer from a company in San Jose, > California. [...] The salary offered is 67k/year [...] I already have > a 60k/year job in Toronto, [...] I was told that the housing prices of > Bay Area will make this salary into a 50k equivalent of Toronto. I think you'll find it to be much worse than that, unless Toronto has a high cost of living (I wouldn't know). Real estate in the San Jose area is very expensive. Not the highest in the US, but close. It's about 2-3 times what it is in the U.S. midwest. > I have a dillema whether: > -Professional advantages of this position, closer to ciruit design. > -Working in Silicon Valley, the Mecca of HighTech. > > outweigh the offered salary ? I wouldn't take it, but YMMV. When I moved from the midwest to San Jose in 1989, it was for a $40K salary. I thought that was great until I got here and discovered that I could barely make ends meet even when sharing a condo. On the other hand, job satisfaction is worth a lot.Article: 77445
In article <2a613f5d.0501052055.3ac008a9@posting.google.com>, vadim <vbishtei@hotmail.com> wrote: >I have received a job offer from a company >in San Jose, California. The position title is: Test Development >Engineering. The salary offered is 67k/year with Relocation Assistance >and a Benefits package. I already have a 60k/year job in Toronto, >Canada as Applications Engineer. > >The San Jose job is closer to circuit-design which is an area I would >like to get into. > >I was told that the housing prices of Bay Area will make this salary >into a 50k equivalent of Toronto. So practically my "buying power" is >reduced. And then some. A little trawling of Craigslist for Santa Clara housing: random studios are about $900 a month (that's single room with kitcheette and bathroom). 2 bdrms are $1300+. Buing is much worse, however. Even a 6 figure income has most bay area houses unaffordable. People ask $490,000 for 2 bedroom, 900 square feet homes in Santa Clara. Yes, thats not a typo, 1/2 a million for a 2 bdrm bungalo. Not to mention that the US dollar has further to drop, and Toronto is not ruled by a President who believes it is more important to be loyal than correct. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 77446
On Thu, 06 Jan 2005 12:23:00 -0700, Bret Wade <bret.wade@xilinx.com> wrote: >Brian Drummond wrote: >> On Wed, 05 Jan 2005 12:06:48 -0700, Bret Wade <bret.wade@xilinx.com> >> wrote: >> I am working with larger RPMs than this, with some degree of success >> (cautiously expressed; the design is not yet complete) >> >> There *may* be problems with BRAMs and multipliers in RPMs. >> >There is a certain amount of complexity added when an RPM combines >multiple component types (Heterogeneous RPM) due to the fact that for >the default grid system, the various component types are on different >grids. This is only a problem if your RPM requires normalization. >http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf This is _very_ good information on RPMs including BRAMS or multipliers or such (IOBs?) which live on different grids. I note S0 and S1 share the same RPM_GRID X value though (unless I misunderstand the floorplanner) they appear in adjacent columns (x, x+1) in floorplanning, e.g. floorplanner and standard grid S2 S3 S0 S1 RPM_GRID S3 S2 S1 S0 The translation given from SLICE_X26Y40 to RPM Grid X42Y84 in the appnote seems to bear this out. >> There are problems using the floorplanner to create RPMs from smaller >> ones, mostly associated with tools issues (the floorplanner alone has >> two mutually incompatible understandings of RLOC_ORIGIN, the mapper >> moves the origin left by 1 location under some (apparently undefined) >> circumstances, the placer reports errors on some correct RLOC_ORIGIN >> constraints and silently deletes others altogether, and so on. > >RLOC_ORIGIN values must take into account the normalization of the RPM. >More on that in the appnote. It's not clear to me quite how that relates to the testcase, which only uses LUTS, SRL16s, and FFs, which are all on the same grid (Spartan-3 restrictions on SRL16 notwithstanding). R0C0 is used, though some elements have negative X values (the floorplanner doesn't give you any choice about this if you don't use the lower left hand corner of the bounding box surrounding the RPM). Is normalisation still an issue in this case? It seems to me that the normalisation is onto the same grid since RPM_GRID is not being used, so I don't see where the problem lies. And outside Xapp416 and this message, I haven't seen any mention of normalisation. Is it described anywhere for the standard grid? Aha! Searching on that word gives the useful looking TechXclusive "Relationally Placed Macros 08/30/2002 " http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iCountryID=1&iLanguageID=1&sTechX_ID=pgse_rpms&BV_SessionID=@@@@0242741689.1105050007@@@@&BV_EngineID=cccgadddhmijmghcflgcefldfhndfnf.0 >The mapper converts RLOC_ORIGINs into MACRO >LOCATE constraints in the PCF file, so strictly speaking it's not >possible for the placer to ignore RLOC_ORIGIN constraints because it >never sees them. True! Strictly speaking the placer ignores the MACRO LOCATE constraints instead. They are in the PCF file, I just checked - see comment above regarding the mapper moving the origin, it does so in the same constraint conversion. >A separate issue is that the RPM needs to be placed in the same "slice >type" that it was created about. There are four slice types represented >by the four slices in a CLB, S0-S3. For simplicitys sake, it is best to >construct a macro about the X0Y0 slice and then always place it in an S0 >slice type if possible. If the RPM is placed in a different slice type, >the relative placement will be broken, which can lead to placement >failures. This may be the problem, but I don't see why the limitation exists. Hand placement of the same components onto the other slice types (again, excepting SRL16s in "odd X" locations) seems to work fine, though not placement of RPMs. >> Maybe FPGA editor is a more stable tool for floorplanning? I would try >> it but only have WebPack in current software. > >FPGA Editor is not a floorplanner. It is an editor for displaying and >modifying the physical design and applying some physical constraints. I have used it (3.1 era) but don't have a current one. >> Can you point me in the direction of a flow that would use guided >> routing for a top level module composed of several pre-routed RPM >> modules? Preferably where at least one of the RPMs has itself been >> created in this way? >Directed Routing is not incompatible with the guided flows. There's no >reason why you can't combine them. You'll just need to get FPGA Editor >and try it. > Interesting, but I think I have been warned off Directed Routing for the size of macros I am using. Is there a way of using routed versions (NCDs?) of several RPMs as (multiple) guide files for a design incorporating them? Your earlier recommendation that "Guide should be used instead" seems to imply that there is, but I can't see it. Many thanks for your answers and help, - BrianArticle: 77447
>"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message >Just upgraded ISE and EDK to 6.3 from 6.2. <snip> > > Sorry, I was not very clear. The UART prints half of the message > > ok, than skips a lot than again a few readable words ... > > > > I did check all the obvious things like baud rate etc. Thats not > > it. There seems some fundamental difference. The SoC seems to > > "hang" as well. Like may be something in the software changed ... > > it still does compile clean, and I did re-compile everything ... > > I spend two days trying to figure out what was wrong, than switched > > back to EDK 6.2. > > > > Thanks, > > rudi > > ============================================================= > > Rudolf Usselmann, ASICS World Services, http://www.asics.ws > > Your Partner for IP Cores, Design, Verification and Synthesis I just upgraded 6.2 to 6.3 and am seeing the same symptoms. Garbled/missing console output and random resets/crashes. If I compile my code under EDK 6.2, it runs fine on the FPGA image created by EDK 6.3. Also, running 6.3 compiled code on a 6.2 FPGA image results in the same misbehavior. I suspect bugs in the GNU tools or libraries. I fixed the console issue by turning off the "Global Pointer Optimization" and by using xil_printf in place of printf. However, even with these changes or with optimization turned off completely, I still get crashes/resets. I have opened a Webcase with Xilinx support and will post any results here. JoeArticle: 77448
> > After which the mapper failes. If I remove the "-timing" option of > the MAP, the mapper succeeds but the PAR failes (unrouted signals). > Any suggestions ? > > Ran > Something to try as a work around would be to lock the the Chipscope RPM down based on either the somewhat successfully non-timing driven run or based on your own judgment. The timing driven packer has some difficulty resolving the placement of RPMs, especially in the presence of area constraints and local clock placement requirements (will improve in 7.1i). With the RPM locked, the timing driven packer is likely to be successful and may resolve the congestion problems you're having with the non-timing driven flow. Regards, BretArticle: 77449
Anyone? "gja" <geeja@hotmail.com> wrote in message news:iAgDd.3927$QK1.1028@fe11.lga... > Tried that, but i get this warning message: > > Started process "Generate Post-Place & Route Simulation Model". > > WARNING:Anno:255 - command line '-s -4' overrides .pcf TEMPERATURE = 70.000 > C > > > > > "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message > news:345bivF47eeulU3@individual.net... > > > > "gja" <geeja@hotmail.com> schrieb im Newsbeitrag > > news:SQdDd.3214$yK7.3065@fe11.lga... > > > I want to do post place and route timing simulation on a Virtex2 part > > using > > > the Xilinx Modelsim starter simulator, how can I set the temperature > point > > > to 70 celcius? > > > > Add > > > > temperature=70C; > > > > to your UCF > > > > Regards > > Falk > > > > > > > > > > > >
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