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
RAM is a primitive- therefore you can use it. Note the first post (RAMB4_S8 was successful). Tim Eric Smith wrote: > Tim Jaynes <tim.jaynes@xilinx.com> writes: > > Macros can only be used if you have a schematic flow- > > If you had a supported schematic tool you could use them in an HDL flow by > > creating a netlist w/ hierarchical ports and instantiating that in your code, > > but as of now schematic entry in WebPACK only supports CPLDs. > > Does this mean that I can't use RAM in my VHDL designs when using > WebPACK? That would seem like quite a limitation.Article: 27076
Hi Steven, Better PAR performance on routing pwr/gnd nets was one of the major enhancements contained in the 3.1i tools and it's associated service packs. Without seeing the design and without knowing your budgetary constraints I'd recommend a software upgrade (assuming that that's a possibility). What I'd do is contact the support hotline (submit a case on the web- support.xilinx.com) to open a case. An engineer here at xilinx could easily run your design in the 3.1i tools to see if that migration fixes the problem- that way you can make sure that an upgrade would be beneficial. Regards, Tim Steven Derrien wrote: > Hi, > > I've some really weird results (design does not route) from PAR for a > Xilinx Virtex design, here is my experimental setup : > > - My design is a 16 stage pipelined floating point > - M2.1 (latest SP) targeting Virtex xcv800 > - It takes no more than 7% of the xcv800 slices... > > > I've tried various implementations with different compress factor (from > -c 1 to -c 0) results are the following : > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > ret_fmul_16 > Target Device : xv800 > Target Package : bg432 > Target Speed : -4 > Mapper Version : virtex -- C.22 > > Design Summary > -------------- > Number of errors: 0 > Number of warnings: 4 > Number of Slices: 724 out of 9,408 7% > Slice Flip Flops: 537 > 4 input LUTs: 629 (13 used as a route-thru) > Shift registers: 173 > Number of Slices containing > unrelated logic: 0 out of 724 0% > Number of bonded IOBs: 97 out of 316 30% > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > ret_fmul_8 > Target Device : xv800 > Target Package : bg432 > Target Speed : -4 > Mapper Version : virtex -- C.22 > > Design Summary > -------------- > Number of errors: 0 > Number of warnings: 3 > Number of Slices: 450 out of 9,408 4% > Slice Flip Flops: 324 > 4 input LUTs: 629 (15 used as a route-thru) > Shift registers: 101 > Number of Slices containing > unrelated logic: 118 out of 450 26% > Number of bonded IOBs: 97 out of 316 30% > > In all cases with and without timing constraints, with multiple PAR > passes, the design always fail to route completely. Specifically GND and > Vcc signals (among others) do not route : below is an example of one of > the PAR report file which ask me to use a larger device while i uses at > most 7% of its slices .... > > What I don't understand is that a relatively equivalent design in terms > of complexity (floating point adder) with much more pipelmine stage and > less regularity place an route successfully !! > > Any Xilinx guru to shed the light on this :) ? > > Steven Derrien > IRISA, France > > Total REAL time: 17 mins 24 secs > Total CPU time: 17 mins 22 secs > End of route. 3897 routed (84.35%); 15 unrouted active, > 708 unrouted PWR/GND. > No errors found. > The signal "mul/C3690_C85O" is not completely routed. > The signal "GLOBAL_LOGIC1" is not completely routed. > The signal "mul/retiming_reg_239Q" is not completely routed. > The signal "mul/retiming_reg_237Q" is not completely routed. > The signal "mul/C3690_C267/O" is not completely routed. > The signal "mul/C3690_C631O" is not completely routed. > The signal "GLOBAL_LOGIC0" is not completely routed. > The signal "mul/C3690_C1008/O" is not completely routed. > The signal "mul/C3690_C1003O" is not completely routed. > The signal "mul/retiming_reg_38Q" is not completely routed. > The signal "mul/C3690_C1420O" is not completely routed. > The signal "mul/retiming_reg_91Q" is not completely routed. > The signal "mul/C3690_C1440O" is not completely routed. > The signal "mul/retiming_reg_97Q" is not completely routed. > The signal "mul/retiming_reg_115Q" is not completely routed. > The signal "mul/C3690_C1493/O" is not completely routed. > The signal "mul/C3690_C1492O" is not completely routed. > > This design was not fully routed. To help fully route the design, you > may try > the following: > * Retarget the design to the next larger device in this family. > > --> I only use 7% of the chip ressource !!!!! > > Total REAL time to Router completion: 17 mins 28 secs > Total CPU time to Router completion: 17 mins 26 secs > > The Number of signals not completely routed for this design is: 17 > > The Average Connection Delay for this design is: 2.890 ns > The Maximum Pin Delay is: 10.541 ns > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > Listing Pin Delays by value: (ns) > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > --------- --------- --------- --------- --------- --------- > 1987 1065 228 246 371 0Article: 27077
There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is your problem. I've seen misplaced carry chain elements generate a similar error. Steven Derrien wrote: > > Hi, > > I've some really weird results (design does not route) from PAR for a > Xilinx Virtex design, here is my experimental setup : > > - My design is a 16 stage pipelined floating point > - M2.1 (latest SP) targeting Virtex xcv800 > - It takes no more than 7% of the xcv800 slices... > > > I've tried various implementations with different compress factor (from > -c 1 to -c 0) results are the following : > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > ret_fmul_16 > Target Device : xv800 > Target Package : bg432 > Target Speed : -4 > Mapper Version : virtex -- C.22 > > Design Summary > -------------- > Number of errors: 0 > Number of warnings: 4 > Number of Slices: 724 out of 9,408 7% > Slice Flip Flops: 537 > 4 input LUTs: 629 (13 used as a route-thru) > Shift registers: 173 > Number of Slices containing > unrelated logic: 0 out of 724 0% > Number of bonded IOBs: 97 out of 316 30% > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > ret_fmul_8 > Target Device : xv800 > Target Package : bg432 > Target Speed : -4 > Mapper Version : virtex -- C.22 > > Design Summary > -------------- > Number of errors: 0 > Number of warnings: 3 > Number of Slices: 450 out of 9,408 4% > Slice Flip Flops: 324 > 4 input LUTs: 629 (15 used as a route-thru) > Shift registers: 101 > Number of Slices containing > unrelated logic: 118 out of 450 26% > Number of bonded IOBs: 97 out of 316 30% > > In all cases with and without timing constraints, with multiple PAR > passes, the design always fail to route completely. Specifically GND and > Vcc signals (among others) do not route : below is an example of one of > the PAR report file which ask me to use a larger device while i uses at > most 7% of its slices .... > > What I don't understand is that a relatively equivalent design in terms > of complexity (floating point adder) with much more pipelmine stage and > less regularity place an route successfully !! > > Any Xilinx guru to shed the light on this :) ? > > Steven Derrien > IRISA, France > > Total REAL time: 17 mins 24 secs > Total CPU time: 17 mins 22 secs > End of route. 3897 routed (84.35%); 15 unrouted active, > 708 unrouted PWR/GND. > No errors found. > The signal "mul/C3690_C85O" is not completely routed. > The signal "GLOBAL_LOGIC1" is not completely routed. > The signal "mul/retiming_reg_239Q" is not completely routed. > The signal "mul/retiming_reg_237Q" is not completely routed. > The signal "mul/C3690_C267/O" is not completely routed. > The signal "mul/C3690_C631O" is not completely routed. > The signal "GLOBAL_LOGIC0" is not completely routed. > The signal "mul/C3690_C1008/O" is not completely routed. > The signal "mul/C3690_C1003O" is not completely routed. > The signal "mul/retiming_reg_38Q" is not completely routed. > The signal "mul/C3690_C1420O" is not completely routed. > The signal "mul/retiming_reg_91Q" is not completely routed. > The signal "mul/C3690_C1440O" is not completely routed. > The signal "mul/retiming_reg_97Q" is not completely routed. > The signal "mul/retiming_reg_115Q" is not completely routed. > The signal "mul/C3690_C1493/O" is not completely routed. > The signal "mul/C3690_C1492O" is not completely routed. > > This design was not fully routed. To help fully route the design, you > may try > the following: > * Retarget the design to the next larger device in this family. > > --> I only use 7% of the chip ressource !!!!! > > Total REAL time to Router completion: 17 mins 28 secs > Total CPU time to Router completion: 17 mins 26 secs > > The Number of signals not completely routed for this design is: 17 > > The Average Connection Delay for this design is: 2.890 ns > The Maximum Pin Delay is: 10.541 ns > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > Listing Pin Delays by value: (ns) > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > --------- --------- --------- --------- --------- --------- > 1987 1065 228 246 371 0 -- -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 or http://www.fpga-guru.comArticle: 27078
Might want to check this site: http://www.fpgacpu.org/ -Jeremy "S. Ramirez" wrote: > Andy, > A "leading" design verification "expert" told me that I could get this > model from the vendor,i.e., Motorola, very easily. "Just ask them," he > said. I have learned from experience that in our business, anyone who has a > quick, fast answer to a complicated problem is just blurting out BS. Of > course this has to be verified. > And so I did. I found the IBIS and BDSL files at the Mot site, but I > couldn't find any behavioral models. So I registered and posted my request > to their technical support team. I got back a response directing me to the > IBIS and BDSL files! A second post telling them that there is a HUGE > difference between these files and what I wanted got me a response back with > a link to the Synopsis site. I have a message in to the local Synopsis rep > asking him for the cost of this model, but I am bracing myself for sticker > shock (and a long wait for the response). This is why I posted the original > message. > At least I know that there are others looking for similar things. I > will post the results when I get them. Hmm, this is what ABC, NBC and CBS > said on the night of the election, and they still don't know! > Thanks. > Simon Ramirez, Consultant > Synchronous Design, Inc. > > "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message > news:8uelp5$rqp$3@noao.edu... > > "S. Ramirez" wrote: > > > > > > Does anyone here know of sources for microprocessor Verilog or VHDL > > > behavioral models? > > > I am doing a board level simulation that involves FPGAs, memories, > > > peanut components, and a Mot ColdFire microprocessor. I checked with > Mot > > > about providing a C behavioral model or an encrypted Verilog/VHDL > behavioral > > > model, and they referred me to the Big S -- Synopsis. This means that > it > > > will cost an ARM and a leg, and I'm not talking about an ARM processor! > > > Does anyone know of alternatives? > > > > Ugh. I'm in the same boat. I started a ColdFire 5206e model a while > > ago -- just bus transactions -- and it's not ready for prime time (other > > things interfered). It would be nice if the chip vendors had some kind > > of USABLE model; then again, they usually don't even have IBIS models, > > so whom are we kidding? > > > > -- a > > ---------------------------- > > Andy Peters > > Sr. Electrical Engineer > > National Optical Astronomy Observatory > > 950 N Cherry Ave > > Tucson, AZ 85719 > > apeters (at) n o a o [dot] e d u > > > > "It is better to be silent and thought a fool, > > than to send an e-mail to the entire company > > and remove all doubt." > >Article: 27079
> Anybody got some code I can scrounge? I'll bet others > have done this already. > > I've got the schematics from the Xilinx web site and > I've worked with peek/poke code to drive the printer > port and I've written code to do the serial download > over home-brew hardware so I'm pretty sure I can do > it all. But why reinvent a wheel if I can scrounge it? Poke around on Xess.com there was some stuff there to drive a Xilinx download cable that I saw. Not sure how relevant, but it was source code... Cheers, Adma -- Adam Hawes Web: http://overfiend.iwarp.com Email: adam_hawes@dingoblue.com.au ICQ: 2492016 Voicemail: +61 (08) 8219-3238 Fax: +61 (08) 8219-3238 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT dpu s+: a-- C++++ UL++ P+ L+++ E W- N+++ o+ K- w--- O- M V-- PS+ PE Y++ PGP++ t 5- X+++ R* tv b+ DI+ D---- G e* h! r--- y** ------END GEEK CODE BLOCK------Article: 27080
Tim, I hope you will forgive an immediate deep-end response, but I am frankly appalled by your reply. You admit you have not seen the user's design but immediately suggest he shells out for an upgrade. I can only hope that you did not notice that the user has only a 7% utilisation within his device. Irrespective of his design type, a failure to route a <any?> design with 7% utilisation is a likely tool bug or fault. Your suggestion that he upgrade to get round the problem is IMNSHO a major cop out and unworthy of you as a representative of Xilinx. I am unaware whether this guy is in maintenance or not but if it turns out he is not, and the solution is indeed that he upgrade to get round a bug, may I suggest he be provided with the upgrade for nowt as the F2.1 he was sold is 'not fit for purpose'. I notice Ray has provided what may be a more constructive reply. Regards, D McLeod XEC Disclaimer: I have assumed that Stephen's design does not contain a fatal error which has caused the tools to give a misleading error message (that never happens). My comments on the 'upgrade regardless' approach remain. "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message news:3A0B11F4.E0AAD7AA@xilinx.com... > Hi Steven, > Better PAR performance on routing pwr/gnd nets was one of the major > enhancements contained in the 3.1i tools and it's associated service packs. > Without seeing the design and without knowing your budgetary constraints I'd > recommend a software upgrade (assuming that that's a possibility). > What I'd do is contact the support hotline (submit a case on the web- > support.xilinx.com) to open a case. An engineer here at xilinx could easily > run your design in the 3.1i tools to see if that migration fixes the > problem- that way you can make sure that an upgrade would be beneficial. > Regards, > Tim >Article: 27081
D McLeod,
I think that Tim is justified in telling Steve that 3.1 might fix the
problem. After all, it might, and this is what matters to Tim. If Tim
doesn't want to shell out the money for 3.1, then so be it -- he should find
a way around his 2.1 problem himself. If 3.1 fixes the problem, then he
goes on with his design.
These tools upgrades do indeed fix problems (and create problems), and
that is one reason they are done.
-Simon Ramirez, Consultant
Synchronous Design, Inc.
"fred" <x@y.z> wrote in message news:8ugerb$dga$1@news6.svr.pol.co.uk...
> Tim,
>
> I hope you will forgive an immediate deep-end response, but
> I am frankly appalled by your reply. You admit you have not
> seen the user's design but immediately suggest he shells out
> for an upgrade. I can only hope that you did not notice that
> the user has only a 7% utilisation within his device.
>
> Irrespective of his design type, a failure to route a <any?>
> design with 7% utilisation is a likely tool bug or fault.
> Your suggestion that he upgrade to get round the problem is
> IMNSHO a major cop out and unworthy of you as a
> representative of Xilinx. I am unaware whether this guy is
> in maintenance or not but if it turns out he is not, and the
> solution is indeed that he upgrade to get round a bug, may I
> suggest he be provided with the upgrade for nowt as the F2.1
> he was sold is 'not fit for purpose'.
>
> I notice Ray has provided what may be a more constructive
> reply.
>
> Regards,
>
> D McLeod
> XEC
>
> Disclaimer: I have assumed that Stephen's design does not
> contain a fatal error which has caused the tools to give a
> misleading error message (that never happens). My comments
> on the 'upgrade regardless' approach remain.
>
> "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message
> news:3A0B11F4.E0AAD7AA@xilinx.com...
> > Hi Steven,
> > Better PAR performance on routing pwr/gnd nets was one of
> the major
> > enhancements contained in the 3.1i tools and it's
> associated service packs.
> > Without seeing the design and without knowing your
> budgetary constraints I'd
> > recommend a software upgrade (assuming that that's a
> possibility).
> > What I'd do is contact the support hotline (submit a case
> on the web-
> > support.xilinx.com) to open a case. An engineer here at
> xilinx could easily
> > run your design in the 3.1i tools to see if that migration
> fixes the
> > problem- that way you can make sure that an upgrade would
> be beneficial.
> > Regards,
> > Tim
> >
>
>
>
>
Article: 27082Hi, How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise. HarryArticle: 27083
"Gary Watson" <gary2@nexsan.com> wrote in message news:IIdO5.7216$Fi.29641@NewsReader... > Someone privately suggested to me that you could put the serial number in > the config prom after the config data, and use an external mux on cclk to > milk the bits out ot the config prom and into an I/O pin. I'm concerned > about the MTBF reduction caused by using a low-tech part in such a critical > area, though it only has to work once, at power up... And another person privately mentioned a trick from the 4000 days -- that the CCLK signal becomes a keeper once the config is complete, and if you simply hook an I/O pin to it and keep clocking it you can read past the config file bits. He didn't know if the Spartan II chips were designed the same way. Anybody? -- Gary Watson gary2@nexsan.com Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 27084
Ray Andraka wrote: > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is > your problem. I've seen misplaced carry chain elements generate a similar > error. > Thank Ray, sounds like you have given to me the probable cause of the problem... Basically i'm working on an "retimer" (or automatic pipeliner) which converts a combinational datapath into a N stage pipelined datapath. My input file is an flatten EDIF description of the datapath. I assume that this edif file only consists of the following virtex primitives : LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then using a very rough delay estimator I place registers in their datapath in order to reduce its critical path. Whe placing registers I took into consideration some constraints due to the Virtex slice topology: - I assume that my orginal EDIF file is consistent with the Virtex architecture (this is the case for example for EDIF generated by F-Compiler2, but not by F-Express) I don't know for other synthesizers. - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that registers are placed correctly between primitives (no registers between a LUT output and XOR input for example) But I did not address the following point : - I didn't made a distinction between MUXCY_L and MUXCY ( neither between XORCY_L and XOR_CY), and that may be the cause of the problem. From what I've guessed from Xilinx documentation, when it founds a "MUXCY_L" primitive, it tries to use carry chain routing (CIN and COUT port of a slice). However my pipeliner can decide to place a register between two MUXCY_L primitives which may cause the par tool to fail to route correctly the design. By the way, I tried the design with M3.2.sp4 (without timing constraints) and it managed to route completely (with very very very poor results anyway). I'll try with timing constraints this afternoon. Thank you for your help, Steven > Steven Derrien wrote: > > > > Hi, > > > > I've some really weird results (design does not route) from PAR for a > > Xilinx Virtex design, here is my experimental setup : > > > > - My design is a 16 stage pipelined floating point > > - M2.1 (latest SP) targeting Virtex xcv800 > > - It takes no more than 7% of the xcv800 slices... > > > > > > I've tried various implementations with different compress factor (from > > -c 1 to -c 0) results are the following : > > > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > > ret_fmul_16 > > Target Device : xv800 > > Target Package : bg432 > > Target Speed : -4 > > Mapper Version : virtex -- C.22 > > > > Design Summary > > -------------- > > Number of errors: 0 > > Number of warnings: 4 > > Number of Slices: 724 out of 9,408 7% > > Slice Flip Flops: 537 > > 4 input LUTs: 629 (13 used as a route-thru) > > Shift registers: 173 > > Number of Slices containing > > unrelated logic: 0 out of 724 0% > > Number of bonded IOBs: 97 out of 316 30% > > > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > > ret_fmul_8 > > Target Device : xv800 > > Target Package : bg432 > > Target Speed : -4 > > Mapper Version : virtex -- C.22 > > > > Design Summary > > -------------- > > Number of errors: 0 > > Number of warnings: 3 > > Number of Slices: 450 out of 9,408 4% > > Slice Flip Flops: 324 > > 4 input LUTs: 629 (15 used as a route-thru) > > Shift registers: 101 > > Number of Slices containing > > unrelated logic: 118 out of 450 26% > > Number of bonded IOBs: 97 out of 316 30% > > > > In all cases with and without timing constraints, with multiple PAR > > passes, the design always fail to route completely. Specifically GND and > > Vcc signals (among others) do not route : below is an example of one of > > the PAR report file which ask me to use a larger device while i uses at > > most 7% of its slices .... > > > > What I don't understand is that a relatively equivalent design in terms > > of complexity (floating point adder) with much more pipelmine stage and > > less regularity place an route successfully !! > > > > Any Xilinx guru to shed the light on this :) ? > > > > Steven Derrien > > IRISA, France > > > > Total REAL time: 17 mins 24 secs > > Total CPU time: 17 mins 22 secs > > End of route. 3897 routed (84.35%); 15 unrouted active, > > 708 unrouted PWR/GND. > > No errors found. > > The signal "mul/C3690_C85O" is not completely routed. > > The signal "GLOBAL_LOGIC1" is not completely routed. > > The signal "mul/retiming_reg_239Q" is not completely routed. > > The signal "mul/retiming_reg_237Q" is not completely routed. > > The signal "mul/C3690_C267/O" is not completely routed. > > The signal "mul/C3690_C631O" is not completely routed. > > The signal "GLOBAL_LOGIC0" is not completely routed. > > The signal "mul/C3690_C1008/O" is not completely routed. > > The signal "mul/C3690_C1003O" is not completely routed. > > The signal "mul/retiming_reg_38Q" is not completely routed. > > The signal "mul/C3690_C1420O" is not completely routed. > > The signal "mul/retiming_reg_91Q" is not completely routed. > > The signal "mul/C3690_C1440O" is not completely routed. > > The signal "mul/retiming_reg_97Q" is not completely routed. > > The signal "mul/retiming_reg_115Q" is not completely routed. > > The signal "mul/C3690_C1493/O" is not completely routed. > > The signal "mul/C3690_C1492O" is not completely routed. > > > > This design was not fully routed. To help fully route the design, you > > may try > > the following: > > * Retarget the design to the next larger device in this family. > > > > --> I only use 7% of the chip ressource !!!!! > > > > Total REAL time to Router completion: 17 mins 28 secs > > Total CPU time to Router completion: 17 mins 26 secs > > > > The Number of signals not completely routed for this design is: 17 > > > > The Average Connection Delay for this design is: 2.890 ns > > The Maximum Pin Delay is: 10.541 ns > > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > > > Listing Pin Delays by value: (ns) > > > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > > --------- --------- --------- --------- --------- --------- > > 1987 1065 228 246 371 0 > > -- > -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 or http://www.fpga-guru.comArticle: 27085
Hi people,
I am using Leonardo Spectrum for altera, trying to use a
synthesizer better than maxplus2 for VHDL. But despite of
checking 'setup maxplus2( create ACF file)option at Place&Route menu,
it didn´t generate any ACF. So every time it runs maxplus2 to P&R it
loses family, device and all information.
Any answer/suggestion is welcome,
Thanks in advance,
Flávio
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 27086As a first cut, you might try changing the _L and _D elements to the generic unsuffixed ones with your parser. Sounds like this is indeed the source of your problems. Steven Derrien wrote: > > Ray Andraka wrote: > > > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is > > your problem. I've seen misplaced carry chain elements generate a similar > > error. > > > > Thank Ray, sounds like you have given to me the probable cause of the > problem... > > Basically i'm working on an "retimer" (or automatic pipeliner) which > converts a combinational datapath into a N stage pipelined datapath. My > input file is an flatten EDIF description of the datapath. I assume that > this edif file only consists of the following virtex primitives : > LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then > using a very rough delay estimator I place registers in their datapath > in order to reduce its critical path. Whe placing registers I took into > consideration some constraints due to the Virtex slice topology: > > - I assume that my orginal EDIF file is consistent with the Virtex > architecture (this is the case for example for EDIF generated by > F-Compiler2, but not by F-Express) I don't know for other synthesizers. > > - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that > registers are placed correctly between primitives (no registers between > a LUT output and XOR input for example) > > But I did not address the following point : > > - I didn't made a distinction between MUXCY_L and MUXCY ( neither > between XORCY_L and XOR_CY), and that may be the cause of the problem. > From what I've guessed from Xilinx documentation, when it founds a > "MUXCY_L" primitive, it tries to use carry chain routing (CIN and COUT > port of a slice). However my pipeliner can decide to place a register > between two MUXCY_L primitives which may cause the par tool to fail to > route correctly the design. > > By the way, I tried the design with M3.2.sp4 (without timing > constraints) and it managed to route completely (with very very very > poor results anyway). I'll try with timing constraints this afternoon. > > Thank you for your help, > > Steven > > > Steven Derrien wrote: > > > > > > Hi, > > > > > > I've some really weird results (design does not route) from PAR for a > > > Xilinx Virtex design, here is my experimental setup : > > > > > > - My design is a 16 stage pipelined floating point > > > - M2.1 (latest SP) targeting Virtex xcv800 > > > - It takes no more than 7% of the xcv800 slices... > > > > > > > > > I've tried various implementations with different compress factor (from > > > -c 1 to -c 0) results are the following : > > > > > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > > > ret_fmul_16 > > > Target Device : xv800 > > > Target Package : bg432 > > > Target Speed : -4 > > > Mapper Version : virtex -- C.22 > > > > > > Design Summary > > > -------------- > > > Number of errors: 0 > > > Number of warnings: 4 > > > Number of Slices: 724 out of 9,408 7% > > > Slice Flip Flops: 537 > > > 4 input LUTs: 629 (13 used as a route-thru) > > > Shift registers: 173 > > > Number of Slices containing > > > unrelated logic: 0 out of 724 0% > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > > > ret_fmul_8 > > > Target Device : xv800 > > > Target Package : bg432 > > > Target Speed : -4 > > > Mapper Version : virtex -- C.22 > > > > > > Design Summary > > > -------------- > > > Number of errors: 0 > > > Number of warnings: 3 > > > Number of Slices: 450 out of 9,408 4% > > > Slice Flip Flops: 324 > > > 4 input LUTs: 629 (15 used as a route-thru) > > > Shift registers: 101 > > > Number of Slices containing > > > unrelated logic: 118 out of 450 26% > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > In all cases with and without timing constraints, with multiple PAR > > > passes, the design always fail to route completely. Specifically GND and > > > Vcc signals (among others) do not route : below is an example of one of > > > the PAR report file which ask me to use a larger device while i uses at > > > most 7% of its slices .... > > > > > > What I don't understand is that a relatively equivalent design in terms > > > of complexity (floating point adder) with much more pipelmine stage and > > > less regularity place an route successfully !! > > > > > > Any Xilinx guru to shed the light on this :) ? > > > > > > Steven Derrien > > > IRISA, France > > > > > > Total REAL time: 17 mins 24 secs > > > Total CPU time: 17 mins 22 secs > > > End of route. 3897 routed (84.35%); 15 unrouted active, > > > 708 unrouted PWR/GND. > > > No errors found. > > > The signal "mul/C3690_C85O" is not completely routed. > > > The signal "GLOBAL_LOGIC1" is not completely routed. > > > The signal "mul/retiming_reg_239Q" is not completely routed. > > > The signal "mul/retiming_reg_237Q" is not completely routed. > > > The signal "mul/C3690_C267/O" is not completely routed. > > > The signal "mul/C3690_C631O" is not completely routed. > > > The signal "GLOBAL_LOGIC0" is not completely routed. > > > The signal "mul/C3690_C1008/O" is not completely routed. > > > The signal "mul/C3690_C1003O" is not completely routed. > > > The signal "mul/retiming_reg_38Q" is not completely routed. > > > The signal "mul/C3690_C1420O" is not completely routed. > > > The signal "mul/retiming_reg_91Q" is not completely routed. > > > The signal "mul/C3690_C1440O" is not completely routed. > > > The signal "mul/retiming_reg_97Q" is not completely routed. > > > The signal "mul/retiming_reg_115Q" is not completely routed. > > > The signal "mul/C3690_C1493/O" is not completely routed. > > > The signal "mul/C3690_C1492O" is not completely routed. > > > > > > This design was not fully routed. To help fully route the design, you > > > may try > > > the following: > > > * Retarget the design to the next larger device in this family. > > > > > > --> I only use 7% of the chip ressource !!!!! > > > > > > Total REAL time to Router completion: 17 mins 28 secs > > > Total CPU time to Router completion: 17 mins 26 secs > > > > > > The Number of signals not completely routed for this design is: 17 > > > > > > The Average Connection Delay for this design is: 2.890 ns > > > The Maximum Pin Delay is: 10.541 ns > > > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > > > > > Listing Pin Delays by value: (ns) > > > > > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > > > --------- --------- --------- --------- --------- --------- > > > 1987 1065 228 246 371 0 > > > > -- > > -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 or http://www.fpga-guru.com -- -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 or http://www.fpga-guru.comArticle: 27087
Hi Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL? Jonas.Article: 27088
Ray Andraka wrote: > > As a first cut, you might try changing the _L and _D elements to the generic > unsuffixed ones with your parser. Sounds like this is indeed the source of your > problems. > Right, but there is (as usual) a problem, output pin for MUXCY and MUX_CY do not have the same names (O for MUXCY and LO for MUXCY_L). So i guess it's going to be non neglectable work :((. By the way do you have references about the routing problem related to an incorrect use of carry chain logic ? I'd like to have more precise info before getting into my retiming code. Thanks again Steven > Steven Derrien wrote: > > > > Ray Andraka wrote: > > > > > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is > > > your problem. I've seen misplaced carry chain elements generate a similar > > > error. > > > > > > > Thank Ray, sounds like you have given to me the probable cause of the > > problem... > > > > Basically i'm working on an "retimer" (or automatic pipeliner) which > > converts a combinational datapath into a N stage pipelined datapath. My > > input file is an flatten EDIF description of the datapath. I assume that > > this edif file only consists of the following virtex primitives : > > LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then > > using a very rough delay estimator I place registers in their datapath > > in order to reduce its critical path. Whe placing registers I took into > > consideration some constraints due to the Virtex slice topology: > > > > - I assume that my orginal EDIF file is consistent with the Virtex > > architecture (this is the case for example for EDIF generated by > > F-Compiler2, but not by F-Express) I don't know for other synthesizers. > > > > - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that > > registers are placed correctly between primitives (no registers between > > a LUT output and XOR input for example) > > > > But I did not address the following point : > > > > - I didn't made a distinction between MUXCY_L and MUXCY ( neither > > between XORCY_L and XOR_CY), and that may be the cause of the problem. > > From what I've guessed from Xilinx documentation, when it founds a > > "MUXCY_L" primitive, it tries to use carry chain routing (CIN and COUT > > port of a slice). However my pipeliner can decide to place a register > > between two MUXCY_L primitives which may cause the par tool to fail to > > route correctly the design. > > > > By the way, I tried the design with M3.2.sp4 (without timing > > constraints) and it managed to route completely (with very very very > > poor results anyway). I'll try with timing constraints this afternoon. > > > > Thank you for your help, > > > > Steven > > > > > Steven Derrien wrote: > > > > > > > > Hi, > > > > > > > > I've some really weird results (design does not route) from PAR for a > > > > Xilinx Virtex design, here is my experimental setup : > > > > > > > > - My design is a 16 stage pipelined floating point > > > > - M2.1 (latest SP) targeting Virtex xcv800 > > > > - It takes no more than 7% of the xcv800 slices... > > > > > > > > > > > > I've tried various implementations with different compress factor (from > > > > -c 1 to -c 0) results are the following : > > > > > > > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > > > > ret_fmul_16 > > > > Target Device : xv800 > > > > Target Package : bg432 > > > > Target Speed : -4 > > > > Mapper Version : virtex -- C.22 > > > > > > > > Design Summary > > > > -------------- > > > > Number of errors: 0 > > > > Number of warnings: 4 > > > > Number of Slices: 724 out of 9,408 7% > > > > Slice Flip Flops: 537 > > > > 4 input LUTs: 629 (13 used as a route-thru) > > > > Shift registers: 173 > > > > Number of Slices containing > > > > unrelated logic: 0 out of 724 0% > > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > > > > ret_fmul_8 > > > > Target Device : xv800 > > > > Target Package : bg432 > > > > Target Speed : -4 > > > > Mapper Version : virtex -- C.22 > > > > > > > > Design Summary > > > > -------------- > > > > Number of errors: 0 > > > > Number of warnings: 3 > > > > Number of Slices: 450 out of 9,408 4% > > > > Slice Flip Flops: 324 > > > > 4 input LUTs: 629 (15 used as a route-thru) > > > > Shift registers: 101 > > > > Number of Slices containing > > > > unrelated logic: 118 out of 450 26% > > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > > > In all cases with and without timing constraints, with multiple PAR > > > > passes, the design always fail to route completely. Specifically GND and > > > > Vcc signals (among others) do not route : below is an example of one of > > > > the PAR report file which ask me to use a larger device while i uses at > > > > most 7% of its slices .... > > > > > > > > What I don't understand is that a relatively equivalent design in terms > > > > of complexity (floating point adder) with much more pipelmine stage and > > > > less regularity place an route successfully !! > > > > > > > > Any Xilinx guru to shed the light on this :) ? > > > > > > > > Steven Derrien > > > > IRISA, France > > > > > > > > Total REAL time: 17 mins 24 secs > > > > Total CPU time: 17 mins 22 secs > > > > End of route. 3897 routed (84.35%); 15 unrouted active, > > > > 708 unrouted PWR/GND. > > > > No errors found. > > > > The signal "mul/C3690_C85O" is not completely routed. > > > > The signal "GLOBAL_LOGIC1" is not completely routed. > > > > The signal "mul/retiming_reg_239Q" is not completely routed. > > > > The signal "mul/retiming_reg_237Q" is not completely routed. > > > > The signal "mul/C3690_C267/O" is not completely routed. > > > > The signal "mul/C3690_C631O" is not completely routed. > > > > The signal "GLOBAL_LOGIC0" is not completely routed. > > > > The signal "mul/C3690_C1008/O" is not completely routed. > > > > The signal "mul/C3690_C1003O" is not completely routed. > > > > The signal "mul/retiming_reg_38Q" is not completely routed. > > > > The signal "mul/C3690_C1420O" is not completely routed. > > > > The signal "mul/retiming_reg_91Q" is not completely routed. > > > > The signal "mul/C3690_C1440O" is not completely routed. > > > > The signal "mul/retiming_reg_97Q" is not completely routed. > > > > The signal "mul/retiming_reg_115Q" is not completely routed. > > > > The signal "mul/C3690_C1493/O" is not completely routed. > > > > The signal "mul/C3690_C1492O" is not completely routed. > > > > > > > > This design was not fully routed. To help fully route the design, you > > > > may try > > > > the following: > > > > * Retarget the design to the next larger device in this family. > > > > > > > > --> I only use 7% of the chip ressource !!!!! > > > > > > > > Total REAL time to Router completion: 17 mins 28 secs > > > > Total CPU time to Router completion: 17 mins 26 secs > > > > > > > > The Number of signals not completely routed for this design is: 17 > > > > > > > > The Average Connection Delay for this design is: 2.890 ns > > > > The Maximum Pin Delay is: 10.541 ns > > > > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > > > > > > > Listing Pin Delays by value: (ns) > > > > > > > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > > > > --------- --------- --------- --------- --------- --------- > > > > 1987 1065 228 246 371 0 > > > > > > -- > > > -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 or http://www.fpga-guru.com > > -- > -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 or http://www.fpga-guru.comArticle: 27089
On Thu, 09 Nov 2000 17:11:25 GMT, Andrea Sorio <a.sorio@libero.it>
wrote:
>Hi
>
> I'm working on my first VHDL design.
>I'm tring to interface the Xilinx PCI core with a MPC860 bus.
>I have same problem with the map application.
>It report this error (one of about 162!)
>
>ERROR:OldMap:648 - BUFT symbol "PCI_CORE/PCI_LC/5/UPPER/T6" (output
> signal=ADIO<22>, enable signal=PCI_CORE/PCI_LC/BAR1_T) on signal
>"ADIO<22>"
> has been reduced to a permanently-driving buffer. (The enable signal
>was
> probably either grounded or reduced to ground.) However, another
>active
> three-state BUFT symbol "USER_APP/BusSwitchC/C513" (output
>signal=ADIO<22>,
> enable signal=USER_APP/BusSwitchC/N430) is driving this signal;
>therefore,
> the signal is multiply sourced.
>
>ModelSim simulation is OK!
>
>I guess that the logic that manage the pci core is reduced to a costant
>value.
>
>Could someone be so kind as to suggest me a plausible cause?
>
>Thank you in advance
>
>Andrea
>
>--
>A.Sorio
>R&D Electronic Engineer
>
>Atenix E.E.
>Via S.Dona' 106
>30170 Mestre (VE)
>ITALY
>
>Tel. +39-041-2621035
>email: andrea.sorio@atenix.it
>
>
Not sure if this is the cause of your problem
But........................
One of the pain in the Butt things about the Xilinx PCI cores is that
certain signals have to be tied to a fixed value via D- Flip-Flops so
that during
compilation some of the logic doesn't get reduce. Oh, You have
make it so that these D-Flip-Flops don't get reduce either. This is
actually explained in their documentation somewhere.
I initially did not do this and found my post-complilation simulation
core driving the bus all of the time
iREQUESTHOLD
iCFG_SELF
iKEEPOUT
iC_READY
iC_TERM
Here are the signals that I tied high/low via output of D-Flip Flop,
not all of these may be required.
good luck
Return Email Address is:
ralphwat dot home at excite dot com
Article: 27090<timjeno@my-deja.com> wrote in message news:8ue9t6$nni$1@nnrp1.deja.com... > I don't know of any such product. I would question whether such an > approach would be the best way to get your "feet wet" anyway. The code > produced by such a process would unlikely be clean and would therefore > offer little help as an educational tool. I can almost gaurantee it > won't do everything you want without tweaking which will ultimately > involve learning VHDL. Basically I agree with all of what you said but not with the conclusion. I do expect "ratty VHDL" to be generated, I do expect to have to learn why it does not do what I expect. But I do think it seems like a good way to learn VHDL. It's also how I expect to be programming FPGA devices in the future. I see VHDL and schematic capture is the equivalent to assembly language. Longer ago then I like to think I learned programming using assemblers. I understand what is happening below the skins. I seldom use assembler any more and when I do I normally start by coding it in C and looking at its output as a starting point. I've moved on to systems that may be a bit sloppy in the details but they handle them so I don't have to. I'd like to apply the same concept to FPGAs. > Besides this, there's a good chance that only a > subset of C would be supported, perhaps a "synthesizable C". This > would involve a learning curve for the C-side also. Yep, expected. > Perhaps a book on VHDL targetted to programmers would work best? I > haven't read any but I could probably at least find names. I'd love to hear of one. Those authors in the audience should take heed. The next source of FPGA developers will come from the software side. The don't want to know logic design they want to know algorythm implementation. > Good luck with whatever you decide to do! Thanks, and thank you for the input. > p.s. - If it helps, I went from a programming background to VHDL. It > requires a conceptual shift but the language is simple. It's similar > to going from C to object oriented C++. The syntax jump is easy but > the concepts are very different. I learned VHDL from VHDL tutorials. > They're all over the place. I've been cruising the net for awhile now looking that the tutorials, there indeed a lot and many are high quality. I have some books on order and have been working on getting an Altera UP1 board. I'll be heading down a comparable path. -- Peter Dennett Email: pdennett@padsoft.com 61 Harbor Lane Web: www.padsoft.com Kemah, TX 77565 Web: www.boatbrains.com Voice: 281 334 3800 Cell: 713 899 6100 Fax: 281 521 1032Article: 27091
You should be able to re-label without too much difficulty. Sure, it's non-trivial but it ain't rocket science either. I don't have a xilinx case reference, as the problem really isn't a tools problem as much as an input error problem, although a more descriptive/pertinent error message would have been helpful in finding it the first time around (in other words, I didn't open a case for this as I considered it my fault). Steven Derrien wrote: > > Ray Andraka wrote: > > > > As a first cut, you might try changing the _L and _D elements to the generic > > unsuffixed ones with your parser. Sounds like this is indeed the source of your > > problems. > > > > Right, but there is (as usual) a problem, output pin for MUXCY and > MUX_CY do not have the same names (O for MUXCY and LO for MUXCY_L). So i > guess it's going to be non neglectable work :((. > > By the way do you have references about the routing problem related to > an incorrect use of carry chain logic ? I'd like to have more precise > info before getting into my retiming code. > > Thanks again > > Steven > > > Steven Derrien wrote: > > > > > > Ray Andraka wrote: > > > > > > > > There were problems with the pwr/gnd routing in 2.1, but I'm not sure that is > > > > your problem. I've seen misplaced carry chain elements generate a similar > > > > error. > > > > > > > > > > Thank Ray, sounds like you have given to me the probable cause of the > > > problem... > > > > > > Basically i'm working on an "retimer" (or automatic pipeliner) which > > > converts a combinational datapath into a N stage pipelined datapath. My > > > input file is an flatten EDIF description of the datapath. I assume that > > > this edif file only consists of the following virtex primitives : > > > LUT,XORCY,MUXCY and MUL_AND (no MUXF5 and MUXF6 for the moment. Then > > > using a very rough delay estimator I place registers in their datapath > > > in order to reduce its critical path. Whe placing registers I took into > > > consideration some constraints due to the Virtex slice topology: > > > > > > - I assume that my orginal EDIF file is consistent with the Virtex > > > architecture (this is the case for example for EDIF generated by > > > F-Compiler2, but not by F-Express) I don't know for other synthesizers. > > > > > > - I merge a LUT with its assoaciated MUXCY and XORCY logic, so that > > > registers are placed correctly between primitives (no registers between > > > a LUT output and XOR input for example) > > > > > > But I did not address the following point : > > > > > > - I didn't made a distinction between MUXCY_L and MUXCY ( neither > > > between XORCY_L and XOR_CY), and that may be the cause of the problem. > > > From what I've guessed from Xilinx documentation, when it founds a > > > "MUXCY_L" primitive, it tries to use carry chain routing (CIN and COUT > > > port of a slice). However my pipeliner can decide to place a register > > > between two MUXCY_L primitives which may cause the par tool to fail to > > > route correctly the design. > > > > > > By the way, I tried the design with M3.2.sp4 (without timing > > > constraints) and it managed to route completely (with very very very > > > poor results anyway). I'll try with timing constraints this afternoon. > > > > > > Thank you for your help, > > > > > > Steven > > > > > > > Steven Derrien wrote: > > > > > > > > > > Hi, > > > > > > > > > > I've some really weird results (design does not route) from PAR for a > > > > > Xilinx Virtex design, here is my experimental setup : > > > > > > > > > > - My design is a 16 stage pipelined floating point > > > > > - M2.1 (latest SP) targeting Virtex xcv800 > > > > > - It takes no more than 7% of the xcv800 slices... > > > > > > > > > > > > > > > I've tried various implementations with different compress factor (from > > > > > -c 1 to -c 0) results are the following : > > > > > > > > > > Command Line : map -r -c 0 -cm speed -detail -o ret_fmul_16_c0 > > > > > ret_fmul_16 > > > > > Target Device : xv800 > > > > > Target Package : bg432 > > > > > Target Speed : -4 > > > > > Mapper Version : virtex -- C.22 > > > > > > > > > > Design Summary > > > > > -------------- > > > > > Number of errors: 0 > > > > > Number of warnings: 4 > > > > > Number of Slices: 724 out of 9,408 7% > > > > > Slice Flip Flops: 537 > > > > > 4 input LUTs: 629 (13 used as a route-thru) > > > > > Shift registers: 173 > > > > > Number of Slices containing > > > > > unrelated logic: 0 out of 724 0% > > > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > > > > > Command Line : map -r -c 1 -cm speed -detail -o ret_fmul_16_c1 > > > > > ret_fmul_8 > > > > > Target Device : xv800 > > > > > Target Package : bg432 > > > > > Target Speed : -4 > > > > > Mapper Version : virtex -- C.22 > > > > > > > > > > Design Summary > > > > > -------------- > > > > > Number of errors: 0 > > > > > Number of warnings: 3 > > > > > Number of Slices: 450 out of 9,408 4% > > > > > Slice Flip Flops: 324 > > > > > 4 input LUTs: 629 (15 used as a route-thru) > > > > > Shift registers: 101 > > > > > Number of Slices containing > > > > > unrelated logic: 118 out of 450 26% > > > > > Number of bonded IOBs: 97 out of 316 30% > > > > > > > > > > In all cases with and without timing constraints, with multiple PAR > > > > > passes, the design always fail to route completely. Specifically GND and > > > > > Vcc signals (among others) do not route : below is an example of one of > > > > > the PAR report file which ask me to use a larger device while i uses at > > > > > most 7% of its slices .... > > > > > > > > > > What I don't understand is that a relatively equivalent design in terms > > > > > of complexity (floating point adder) with much more pipelmine stage and > > > > > less regularity place an route successfully !! > > > > > > > > > > Any Xilinx guru to shed the light on this :) ? > > > > > > > > > > Steven Derrien > > > > > IRISA, France > > > > > > > > > > Total REAL time: 17 mins 24 secs > > > > > Total CPU time: 17 mins 22 secs > > > > > End of route. 3897 routed (84.35%); 15 unrouted active, > > > > > 708 unrouted PWR/GND. > > > > > No errors found. > > > > > The signal "mul/C3690_C85O" is not completely routed. > > > > > The signal "GLOBAL_LOGIC1" is not completely routed. > > > > > The signal "mul/retiming_reg_239Q" is not completely routed. > > > > > The signal "mul/retiming_reg_237Q" is not completely routed. > > > > > The signal "mul/C3690_C267/O" is not completely routed. > > > > > The signal "mul/C3690_C631O" is not completely routed. > > > > > The signal "GLOBAL_LOGIC0" is not completely routed. > > > > > The signal "mul/C3690_C1008/O" is not completely routed. > > > > > The signal "mul/C3690_C1003O" is not completely routed. > > > > > The signal "mul/retiming_reg_38Q" is not completely routed. > > > > > The signal "mul/C3690_C1420O" is not completely routed. > > > > > The signal "mul/retiming_reg_91Q" is not completely routed. > > > > > The signal "mul/C3690_C1440O" is not completely routed. > > > > > The signal "mul/retiming_reg_97Q" is not completely routed. > > > > > The signal "mul/retiming_reg_115Q" is not completely routed. > > > > > The signal "mul/C3690_C1493/O" is not completely routed. > > > > > The signal "mul/C3690_C1492O" is not completely routed. > > > > > > > > > > This design was not fully routed. To help fully route the design, you > > > > > may try > > > > > the following: > > > > > * Retarget the design to the next larger device in this family. > > > > > > > > > > --> I only use 7% of the chip ressource !!!!! > > > > > > > > > > Total REAL time to Router completion: 17 mins 28 secs > > > > > Total CPU time to Router completion: 17 mins 26 secs > > > > > > > > > > The Number of signals not completely routed for this design is: 17 > > > > > > > > > > The Average Connection Delay for this design is: 2.890 ns > > > > > The Maximum Pin Delay is: 10.541 ns > > > > > The Average Connection Delay on the 10 Worst Nets is: 7.578 ns > > > > > > > > > > Listing Pin Delays by value: (ns) > > > > > > > > > > d < 2.00 < d < 4.00 < d < 6.00 < d < 8.00 < d < 11.00 d >= 11.00 > > > > > --------- --------- --------- --------- --------- --------- > > > > > 1987 1065 228 246 371 0 > > > > > > > > -- > > > > -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 or http://www.fpga-guru.com > > > > -- > > -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 or http://www.fpga-guru.com -- -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 or http://www.fpga-guru.comArticle: 27092
> Not sure if this is the cause of your problem > But........................ > One of the pain in the Butt things about the Xilinx PCI cores is that > certain signals have to be tied to a fixed value via D- Flip-Flops so > that during > compilation some of the logic doesn't get reduce. Oh, You have > make it so that these D-Flip-Flops don't get reduce either. This is > actually explained in their documentation somewhere. > > I initially did not do this and found my post-complilation simulation > core driving the bus all of the time > > iREQUESTHOLD > iCFG_SELF > iKEEPOUT > iC_READY > iC_TERM > > Here are the signals that I tied high/low via output of D-Flip Flop, > not all of these may be required. > Yes I done it. Bye Andrea -- A.Sorio R&D Electronic Engineer Atenix E.E. Via S.Dona' 106 30170 Mestre (VE) ITALY Tel. +39-041-2621035 email: andrea.sorio@atenix.itArticle: 27093
Fred, You'll note that the key to my arguement is the fact that I recommended the customer contact our _free_ support service to verify my suggestion. And it was just that- a suggestion. I'm not a salesman- just a support engineer, trying to give people on this news group a hand when I can. Regards, Tim fred wrote: > Tim, > > I hope you will forgive an immediate deep-end response, but > I am frankly appalled by your reply. You admit you have not > seen the user's design but immediately suggest he shells out > for an upgrade. I can only hope that you did not notice that > the user has only a 7% utilisation within his device. > > Irrespective of his design type, a failure to route a <any?> > design with 7% utilisation is a likely tool bug or fault. > Your suggestion that he upgrade to get round the problem is > IMNSHO a major cop out and unworthy of you as a > representative of Xilinx. I am unaware whether this guy is > in maintenance or not but if it turns out he is not, and the > solution is indeed that he upgrade to get round a bug, may I > suggest he be provided with the upgrade for nowt as the F2.1 > he was sold is 'not fit for purpose'. > > I notice Ray has provided what may be a more constructive > reply. > > Regards, > > D McLeod > XEC > > Disclaimer: I have assumed that Stephen's design does not > contain a fatal error which has caused the tools to give a > misleading error message (that never happens). My comments > on the 'upgrade regardless' approach remain. > > "Tim Jaynes" <tim.jaynes@xilinx.com> wrote in message > news:3A0B11F4.E0AAD7AA@xilinx.com... > > Hi Steven, > > Better PAR performance on routing pwr/gnd nets was one of > the major > > enhancements contained in the 3.1i tools and it's > associated service packs. > > Without seeing the design and without knowing your > budgetary constraints I'd > > recommend a software upgrade (assuming that that's a > possibility). > > What I'd do is contact the support hotline (submit a case > on the web- > > support.xilinx.com) to open a case. An engineer here at > xilinx could easily > > run your design in the 3.1i tools to see if that migration > fixes the > > problem- that way you can make sure that an upgrade would > be beneficial. > > Regards, > > Tim > >Article: 27094
Hi > bidirectional data pins are implemented in VHDL; the synthesis tool > correctly places IOBUF's. Functional simulation is o.k. > But MAP removes all output signals including the tristate > control signal, and replaces all IOBUF's by IBUF's. > I had a similar problem with FPGAExpress. I have a bidir data bus that feed some r/w register. the simulation is ok, but fpgaexpress place a outb instead of a iobuf (obuft + inbuf). I created a process to manage the bidir bus at top level. lddd = internal bus DDD = external bus lddd <= DDD when (RW_N = '0') else "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"; DDD <= lddd when (RW_N = '1') else "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"; RW_N is an input signale managed from a up. In this way the FPGAExpress instantiates a outbt and an inbuf. Good luck! Bye Andrea -- A.Sorio R&D Electronic Engineer Atenix E.E. Via S.Dona' 106 30170 Mestre (VE) ITALY Tel. +39-041-2621035 email: andrea.sorio@atenix.itArticle: 27095
Harry, There are a couple options available to you. For the best description go to: http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=6214 This is a xilinx answer entitled 'Virtex - How do I use the registers/Flip-Flops in the IOB'. It's answer #6214. Regards, Tim Harry wrote: > Hi, > How to instantiate FFs in Xilinx IOBs in VHDL?? Please advise. > HarryArticle: 27096
Jonas wrote: > > Hi > Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL? I think you have to add the pullup in the P+R stage, by placing a PULLUP constraint on the pin. The open-drain output is easy: outpin <= '0' when en_l = '0' else 'Z'; Note that FPGA Express (up to and including v3.4) is stupid and requires active-low tristate enables, even tho' the chip architecture has a polarity-select mux. I haven't tested this with Synplify. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27097
Jeremy Cooke wrote: > > Might want to check this site: > > http://www.fpgacpu.org/ Jeremy, Simon doesn't want to put the CPU into the FPGA. He just wants to simulate his FPGA as connected to an off-the-shelf Motorola CPU. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27098
Correct!!! Besides, the ColdFire isn't in there. -SImon Ramirez, Consultant Synchronous Design, Inc. "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message news:8uhb7o$10qi$3@noao.edu... > Jeremy Cooke wrote: > > > > Might want to check this site: > > > > http://www.fpgacpu.org/ > > Jeremy, > > Simon doesn't want to put the CPU into the FPGA. He just wants to > simulate his FPGA as connected to an off-the-shelf Motorola CPU. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > > "It is better to be silent and thought a fool, > than to send an e-mail to the entire company > and remove all doubt." >Article: 27099
It is possible, however I strongly recommend you use an external pullup. The internal pull ups are weak pull ups sufficient to tie an unconnected pin high. However when that pin has a trace and loads attached, the pull up value is really too small to ensure a) that the trace does not act as an antenna and b) that the open drain output goes back high in a reasonable amount of time. The high impedance (>100K) of the internal pullup does little to guarantee this. Andy Peters wrote: > > Jonas wrote: > > > > Hi > > Is it possible to configurate a pin as an open drain and at the same time use an internal pull up? I use a SpartanXL (XCS40XL). If this i possible, how do I describe it in VHDL? > > I think you have to add the pullup in the P+R stage, by placing a PULLUP > constraint on the pin. > > The open-drain output is easy: > > outpin <= '0' when en_l = '0' else 'Z'; > > Note that FPGA Express (up to and including v3.4) is stupid and requires > active-low tristate enables, even tho' the chip architecture has a > polarity-select mux. I haven't tested this with Synplify. > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > > "It is better to be silent and thought a fool, > than to send an e-mail to the entire company > and remove all doubt." -- -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 or http://www.fpga-guru.com
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