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
On Thursday, July 28, 2016 at 4:47:52 AM UTC+3, KJ wrote: > On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote: > > Vivado is supposed to be really fast, but I've noticed it parses really= slowly. To test this I timed it. I have a design with about 20 lines of = code. It uses an undeclared reg. If I try to compile with with Modelsim f= rom the command line, I get an error immediately. I mean, I can't even tim= e it because the error message appears while my pinky is still on the carri= age return. When I try to synthesize with Vivado, it takes over 20 seconds= just to tell me I have an undeclared reg. That seems like a really long t= ime. > >=20 > > Also, it takes over 3 minutes to P&R this design, which comprises a con= stant mult with 50 LUTs. Seems pretty slow. >=20 > If Brand X isn't up to snuff, maybe switch to Brand I, formerly A. >=20 > Kevin Jennings Quartus2 v.15.x suffers from similar problems. Finding syntax errors in small designs is 10-20 times slower than, for exam= ple, in v.9.1. Not just syntax checks, all phases of processing of small designs in v.15.x= feel MUCH slower than in earlier versions. May be, except for timing analy= sis.Article: 159101
Hi, I am using a max 10 FPGA, and trying to communicate with an I2C slave. I am using the HSMC connector to connect to another board where the I2C sla= ve is located. I have tested the SDA and SCL lines, so I know they are mapped through the = HSMC port correctly. Then I added pullup resistors to the I2C slave PCB, pu= lling the line to 3.3v. However, when I program the FPGA both SDA and SCL l= ines get pulled down to 1.9V, so it seems like they are driving against the= pullup instead if beeing tri-stated? I have added OPNDRN primitives to the output pins and according to the synt= hesis report, the output pins are configures as opendrain. Is there any oth= er type of configuration that needs to be set?Article: 159102
On 07/29/2016 01:21 AM, tomberge@gmail.com wrote: > Hi, > > I am using a max 10 FPGA, and trying to communicate with an I2C slave. > I am using the HSMC connector to connect to another board where the I2C slave is located. > I have tested the SDA and SCL lines, so I know they are mapped through the HSMC port correctly. Then I added pullup resistors to the I2C slave PCB, pulling the line to 3.3v. However, when I program the FPGA both SDA and SCL lines get pulled down to 1.9V, so it seems like they are driving against the pullup instead if beeing tri-stated? > I have added OPNDRN primitives to the output pins and according to the synthesis report, the output pins are configures as opendrain. Is there any other type of configuration that needs to be set? > Your output structure needs to support it. In Verilog, this works: tri1 SCL, SDA; // out to pins // internal use signals wire SCL_in, SDA_in; wire SDA_out, SCL_out; // hookup the pin signals assign SDA = SDA_out ? 1'bz : 1'b0; assign SCL = SCL_out ? 1'bz : 1'b0; // grab the input values assign SCL_in = SCL; assign SDA_in = SDA;Article: 159103
On Fri, 29 Jul 2016 01:21:44 -0700, tomberge wrote: > Hi, > > I am using a max 10 FPGA, and trying to communicate with an I2C slave. > I am using the HSMC connector to connect to another board where the I2C > slave is located. > I have tested the SDA and SCL lines, so I know they are mapped through > the HSMC port correctly. Then I added pullup resistors to the I2C slave > PCB, pulling the line to 3.3v. However, when I program the FPGA both SDA > and SCL lines get pulled down to 1.9V, so it seems like they are driving > against the pullup instead if beeing tri-stated? > I have added OPNDRN primitives to the output pins and according to the > synthesis report, the output pins are configures as opendrain. Is there > any other type of configuration that needs to be set? What is powering that output bank? If it's powered by 1.8V, are the pins compatible with higher supply voltages? 1.9V sounds like an open-drain output that's powered by 1.8V and isn't 3.3V compatible. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159104
rickman wrote: > > I have already tried running Synplify manually and it does not start > bringing up an error report that doesn't say anything about the error > Just to clarify, does that same error also happen if you run Synplify completely outside of Diamond, from the Start Menu under Lattice_Diamond_xxx/Accessories? > > returns an error 3 when from from within Diamond. > >From page 496 of C:\lscc\diamond\3.7_x64\synpbase\doc\user_guide.pdf " " The software uses the following error codes: " 0 - OK " 2 - logical error " 3 - startup failure " 4 - licensing failure " ... " 'Startup Failure' sounds to me like an install or DLL issue- I'd try a clean install and/or running under a DLL checker like DependencyWalker. -BrianArticle: 159105
On 7/29/2016 7:25 PM, Brian Davis wrote: > rickman wrote: >> >> I have already tried running Synplify manually and it does not start >> bringing up an error report that doesn't say anything about the error >> > Just to clarify, does that same error also happen if you run Synplify completely outside of Diamond, from the Start Menu under Lattice_Diamond_xxx/Accessories? > >> >> returns an error 3 when from from within Diamond. >> > From page 496 of C:\lscc\diamond\3.7_x64\synpbase\doc\user_guide.pdf > " > " The software uses the following error codes: > " 0 - OK > " 2 - logical error > " 3 - startup failure > " 4 - licensing failure > " ... > " > > 'Startup Failure' sounds to me like an install or DLL issue- I'd try a clean install and/or running under a DLL checker like DependencyWalker. Thanks for the info. I've already done the uninstall and install again thing. How do you trouble shoot something like this? I'm getting zero help from Lattice. -- Rick CArticle: 159106
On 07/28/2016 03:48 AM, Kevin Neilson wrote: > Interestingly, the following loop also implements the multiply as a > lookup table with 1 LUT per output bit without having to write out > the case statement. > > reg [5:0] x; integer ii; always@(posedge i_clk) for (ii=0; ii<64; > ii=ii+1) if (x==ii) p <= 956*ii; > > > One thing you have to do in this field is to constantly look at the > synthesized design to see if it came out how you'd planned. That is > something high-level users aren't supposed to have to do. Imagine if > a Javascript coder had to look at the compiled machine code to see if > the compiler did what he wanted. I don't think they work on that > level. > looks like they don't do optimization on that stuff... have you tried yosys? I'm pretty sure It'll do that for you. or perhaps bare ABC... if you have some other way to convert to blif or AIG or sthg... or perhaps you've missed some synth option...?Article: 159107
I imagine Synplify would do a better job, but I don't have it. It seems li= ke Vivado just wants to do any multiplication in a DSP48, and if you don't = do that, it has poor heuristics. If I were going to need this a lot, I'd j= ust make my own function with some good heuristics (e.g., if it's a constan= t mult and the constant has a CSD representation with <=3D3 ones, then use = a ternary adder...). I would've expected these rules to have been build in= to the synthesizer, though. It's pretty basic.Article: 159108
On Sat, 30 Jul 2016 12:11:28 -0700, Kevin Neilson wrote: > I imagine Synplify would do a better job, but I don't have it. It seems > like Vivado just wants to do any multiplication in a DSP48, and if you > don't do that, it has poor heuristics. If I were going to need this a > lot, I'd just make my own function with some good heuristics (e.g., if > it's a constant mult and the constant has a CSD representation with <=3 > ones, then use a ternary adder...). I would've expected these rules to > have been build into the synthesizer, though. It's pretty basic. Speaking as someone who does mostly software and circuit design, with enough FPGA knowledge to be dangerous -- the optimizer doesn't seem to be trying very hard. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159109
On Sat, 30 Jul 2016 12:11:28 -0700, Kevin Neilson wrote: > I imagine Synplify would do a better job, but I don't have it. It seems > like Vivado just wants to do any multiplication in a DSP48, and if you > don't do that, it has poor heuristics. If I were going to need this a > lot, I'd just make my own function with some good heuristics (e.g., if > it's a constant mult and the constant has a CSD representation with <=3 > ones, then use a ternary adder...). I would've expected these rules to > have been build into the synthesizer, though. It's pretty basic. Could it be that when you tell the thing to not use a DSP block it's interpreting that to mean "just don't optimize this"? -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159110
On Thursday, July 28, 2016 at 12:09:12 PM UTC+2, Theo Markettos wrote: > Jakab Tanko <jakab.tanko@gmail.com> wrote: > > Hi all, > > > > I have a design that uses Altera Ethernet MAC and > > I would like to connect it to NIOS without DMA. > > Any suggestions? > > The MAC (at least the 10G MAC which I've worked with) has Avalon stream > pipes in and out for packet data. So you just need something to generate a > stream of 64 bit words. The Altera supplied stream-to-memory-mapped > components only go as wide as 32 bits. So I wrote a very simple FIFO to > stream converter, with 64 bit Avalon ST and 32 bit Avalon MM ports. Write > words into a pair of 32 bit FIFO registers, 64 bit words come out on the > stream. Another register handles start-of-packet/end-of-packet bits. > > You probably don't want my code (it's in Bluespec), but it shouldn't take > long to write something similar. Alternatively you could use the Altera 32 > bit components and make something to double up two words on a 32 bit stream > to be a single 64 bit stream word. > > Theo Hi Theo, Thanks for the reply, In this design I have the 1G MAC but the problem is the same; Can't connect Avalon streaming ports (ST) to the NIOS directly so I will follow what you did and build my own bridge(s), Cheers, JakabArticle: 159111
On Friday, July 29, 2016 at 1:32:43 AM UTC+3, already...@yahoo.com wrote: > On Thursday, July 28, 2016 at 4:47:52 AM UTC+3, KJ wrote: > > On Wednesday, July 27, 2016 at 7:21:26 PM UTC-4, Kevin Neilson wrote: > > > Vivado is supposed to be really fast, but I've noticed it parses real= ly slowly. To test this I timed it. I have a design with about 20 lines o= f code. It uses an undeclared reg. If I try to compile with with Modelsim= from the command line, I get an error immediately. I mean, I can't even t= ime it because the error message appears while my pinky is still on the car= riage return. When I try to synthesize with Vivado, it takes over 20 secon= ds just to tell me I have an undeclared reg. That seems like a really long= time. > > >=20 > > > Also, it takes over 3 minutes to P&R this design, which comprises a c= onstant mult with 50 LUTs. Seems pretty slow. > >=20 > > If Brand X isn't up to snuff, maybe switch to Brand I, formerly A. > >=20 > > Kevin Jennings >=20 > Quartus2 v.15.x suffers from similar problems. > Finding syntax errors in small designs is 10-20 times slower than, for ex= ample, in v.9.1. > Not just syntax checks, all phases of processing of small designs in v.15= .x feel MUCH slower than in earlier versions. May be, except for timing ana= lysis. Out of interest, I went to quantify my feelings about slowness of small des= igns in Quartus Prime v.15.1 relatively to previous versions. Here are results for project with ~250 LEs. Analysis & Syntesis: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 2s 2s N/A Cyclone IV E 2s 2s 11s Stratix IV 4s 2s 12s Cyclone V EB N/A 2s 12s Fitter: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 3s 4s N/A Cyclone IV E 2s 4s 4s Stratix IV 29s 20s 19s Cyclone V EB N/A 20s 24s Timing Analysis: Device Time Quartus II 9.1 Quartus II 13.1 Quartus Prime 15.1 Cyclone III 2s 2s N/A Cyclone IV E 1s 2s 2s Stratix IV 4s 3s 3s Cyclone V EB N/A 7s 7s So, slowdown of Analysis & Syntesis is not my imagination, it is very real = and certainly pushes the time from category "fast enough" (at least on fast= CPU/SSD as in my tests) into category "annoying, disrupts a flow of thinki= ng". On the other hand, slowdown of fitter is related to new devices (Startix IV= and all '5' series) rather than to specific version of Quartus software.Article: 159112
Interesting. I haven't used Synplify in a while, but I feel like it would parse & synthesize small designs in a matter of seconds. On the other hand, I made a test case for Vivado: Vivado 2016.2 Test Case: Module with One Flipflop --------------------------------------------------- Synthesis time: 58s Place & Route: 1:58s Synth & PAR Together: 2:40 Seems pretty weak. Does not even include time to "open" design. I do a lot of small test cases in order to get synthesis right and trying different things on these small designs eats up a lot of my time. I might remind you, this design contained one flipflop. I don't know how fast the computer is, but it was very lightly loaded.Article: 159113
On Tuesday, August 2, 2016 at 7:51:38 PM UTC+3, Kevin Neilson wrote: > Interesting. I haven't used Synplify in a while, but I feel like it woul= d parse & synthesize small designs in a matter of seconds. On the other ha= nd, I made a test case for Vivado: >=20 > Vivado 2016.2 Test Case: Module with One Flipflop > --------------------------------------------------- > Synthesis time: 58s > Place & Route: 1:58s > Synth & PAR Together: 2:40 >=20 > Seems pretty weak. Does not even include time to "open" design. I do a = lot of small test cases in order to get synthesis right and trying differen= t things on these small designs eats up a lot of my time.=20 >=20 > I might remind you, this design contained one flipflop. I don't know how= fast the computer is, but it was very lightly loaded. I can't confirm your results. According to my measurement, Vivado handling of small designs *is* awfully = slow. but not nearly as slow as you suggest. I tested with the same design that I used for comparison of versions of Qua= rtus. The Vivado test computer was somewhat slower than the one I was using with = Quartus (Core i7-3770 vs Xeon E3-1271 v3), but also had fast SSD. I specified the smallest of all Zync devices - xc7z010iclg225-1L. Synthesis took 23s (wall clock time) Implementation took 42s=20 And remember, my test case was significantly bigger than yours. So, either something is wrong in your project settings or you should buy fa= ster computer. That is, not more cores, the 2nd CPU core only helps by few = per cents and any number of cores above 2 makes no difference at all, but f= aster cores. And, of course, good fast SSD.Article: 159114
Yes, these results do seem unreasonably bad. I'll try a different computer.Article: 159115
El jueves, 28 de julio de 2016, 22:53:29 (UTC+10), Gabor escribi=C3=B3: > Kevin Neilson wrote: > > Vivado is supposed to be really fast, but I've noticed it parses really= slowly. To test this I timed it. I have a design with about 20 lines of = code.. It uses an undeclared reg. If I try to compile with with Modelsim = from the command line, I get an error immediately. I mean, I can't even ti= me it because the error message appears while my pinky is still on the carr= iage return. When I try to synthesize with Vivado, it takes over 20 second= s just to tell me I have an undeclared reg. That seems like a really long = time. > >=20 > > Also, it takes over 3 minutes to P&R this design, which comprises a con= stant mult with 50 LUTs. Seems pretty slow. >=20 > I've just started using Vivado, which was supposed to be a ground-up > totally new software with no inheritance from ISE. However I have > already noticed that it has some of the same quirks that ISE does. > One thing I noticed in ISE, and it may be related to the time you > take to find an error, is that when you ask to check syntax on one > module it actually parses the entire design hierarchy - even if the > module you wanted checked is only in the project but not a part of > the design hierarchy. Other quirks include pointing to a different > net when reporting a multi-driven net. Generally when Vivado reports > a multi-driven net there is one somewhere in the design, just not the > net it is reporting. Good luck finding the actual net. I used to > have a similar issue in ISE where it would report GND as multi-driven. >=20 > What was clearly a totally new design is the user interface. Even when > Vivado has the exact same function as ISE you need to know the new name > to find it. For example, "IP Integrator" is clearly Core Generator > just repackaged for Vivado. >=20 > By the way, when you say Vivado took 20 seconds to find the error, > was that running simulation or synthesis? >=20 > --=20 > Gabor The multi-driven net problem was a headache in=20 ISE. In vivado you'll also get an obscure report about some net being multi= -driven, but you can workaround it quite easily doing a post-synthesis DRC = check, it will show more clearly which nets are conflicting.Article: 159116
On Thursday, July 28, 2016 at 2:21:26 AM UTC+3, Kevin Neilson wrote: > Vivado is supposed to be really fast, but I've noticed it parses really s= lowly. To test this I timed it. I have a design with about 20 lines of co= de. It uses an undeclared reg. If I try to compile with with Modelsim fro= m the command line, I get an error immediately. I mean, I can't even time = it because the error message appears while my pinky is still on the carriag= e return. When I try to synthesize with Vivado, it takes over 20 seconds j= ust to tell me I have an undeclared reg. That seems like a really long tim= e. >=20 > Also, it takes over 3 minutes to P&R this design, which comprises a const= ant mult with 50 LUTs. Seems pretty slow. BTW, if you are new to Vivado then you possibly didn't pay attention to "on= -the-fly" syntax checking feature. This feature allows to catch simple syntax mistakes without running synthes= is. Just open your HDL source in the editor and follow red marks. In VHDL = undeclared signals are caught by "on-the-fly" checker just fine. I don't kn= ow if they are caught in Verilog as well.Article: 159117
A recurring theme all this talk of slower FPGA software. I been using Lattice FPGA to create small CPUs and notice that the newer versions of the Diamond software is considerably slower that some of the older versions also by several factors. So one wonders how can all these software packages suffer from a major slowdown in performance. Maybe some commonly used libraries? On 8/4/2016 7:20 AM, already5chosen@yahoo.com wrote: > On Thursday, July 28, 2016 at 2:21:26 AM UTC+3, Kevin Neilson wrote: >> Vivado is supposed to be really fast, but I've noticed it parses really slowly. To test this I timed it. I have a design with about 20 lines of code. It uses an undeclared reg. If I try to compile with with Modelsim from the command line, I get an error immediately. I mean, I can't even time it because the error message appears while my pinky is still on the carriage return. When I try to synthesize with Vivado, it takes over 20 seconds just to tell me I have an undeclared reg. That seems like a really long time. >> >> Also, it takes over 3 minutes to P&R this design, which comprises a constant mult with 50 LUTs. Seems pretty slow. > > BTW, if you are new to Vivado then you possibly didn't pay attention to "on-the-fly" syntax checking feature. > > This feature allows to catch simple syntax mistakes without running synthesis. Just open your HDL source in the editor and follow red marks. In VHDL undeclared signals are caught by "on-the-fly" checker just fine. I don't know if they are caught in Verilog as well. > -- Cecil - k5nwaArticle: 159118
Cecil Bayona <cbayona@cbayona.com> wrote: > A recurring theme all this talk of slower FPGA software. I been using > Lattice FPGA to create small CPUs and notice that the newer versions of > the Diamond software is considerably slower that some of the older > versions also by several factors. So one wonders how can all these > software packages suffer from a major slowdown in performance. Maybe > some commonly used libraries? My guess would be the synthesis process has become more heavyweight as time has gone on. Modern FPGAs are much larger than older ones, which means more housekeeping / management of data structures, databases, libraries etc and a more complex flow. I wouldn't be surprised if this causes more initial setup, with the expectation this will be paid back by making building a complex design quicker. They probably aren't optimised for building very simple designs. TheoArticle: 159119
On 8/4/2016 10:39 AM, Theo Markettos wrote: > Cecil Bayona <cbayona@cbayona.com> wrote: >> A recurring theme all this talk of slower FPGA software. I been using >> Lattice FPGA to create small CPUs and notice that the newer versions of >> the Diamond software is considerably slower that some of the older >> versions also by several factors. So one wonders how can all these >> software packages suffer from a major slowdown in performance. Maybe >> some commonly used libraries? > > My guess would be the synthesis process has become more heavyweight as time > has gone on. Modern FPGAs are much larger than older ones, which means more > housekeeping / management of data structures, databases, libraries etc and a > more complex flow. > > I wouldn't be surprised if this causes more initial setup, with the > expectation this will be paid back by making building a complex design > quicker. They probably aren't optimised for building very simple designs. > > Theo > I my case this is compared to a couple of revisions back but you are right I'm currently using a Brevia 2, not a big FPGA, it the smallest device in it's family, and I'm using less than half of the logic, in some cases way less than half the logic. The wait has changed from 20 seconds or less to build the whole project to several minutes making it an annoyance to have to build the entire project. Still compared to using real hardware and changing the wiring, which would make the project quite a difficult task to change, using a FPGA is quite liberating. -- Cecil - k5nwaArticle: 159120
On Thursday, August 4, 2016 at 6:40:03 PM UTC+3, Theo Markettos wrote: > Cecil Bayona <cbayona@cbayona.com> wrote: > > A recurring theme all this talk of slower FPGA software. I been using= =20 > > Lattice FPGA to create small CPUs and notice that the newer versions of= =20 > > the Diamond software is considerably slower that some of the older=20 > > versions also by several factors. So one wonders how can all these=20 > > software packages suffer from a major slowdown in performance. Maybe=20 > > some commonly used libraries? >=20 > My guess would be the synthesis process has become more heavyweight as ti= me > has gone on. Modern FPGAs are much larger than older ones, which means m= ore > housekeeping / management of data structures, databases, libraries etc an= d a > more complex flow. >=20 > I wouldn't be surprised if this causes more initial setup, with the > expectation this will be paid back by making building a complex design > quicker. They probably aren't optimised for building very simple designs= . >=20 > Theo That's the theory. In practice, for non-tiny designs (compilation of several minutes) I don't = see that initial slowness pays back. Mostly I see the same ~10s difference = between Quartus II 13.1 and Quartus Prime 15.1 that I measured on tiny desi= gns, persists on bigger designs as well. May be, for designs that take dozens of minutes it would be different. I am= certainly not going to measure.Article: 159121
On 8/4/2016 11:55 AM, Cecil Bayona wrote: > > > On 8/4/2016 10:39 AM, Theo Markettos wrote: >> Cecil Bayona <cbayona@cbayona.com> wrote: >>> A recurring theme all this talk of slower FPGA software. I been using >>> Lattice FPGA to create small CPUs and notice that the newer versions of >>> the Diamond software is considerably slower that some of the older >>> versions also by several factors. So one wonders how can all these >>> software packages suffer from a major slowdown in performance. Maybe >>> some commonly used libraries? >> >> My guess would be the synthesis process has become more heavyweight as >> time >> has gone on. Modern FPGAs are much larger than older ones, which >> means more >> housekeeping / management of data structures, databases, libraries etc >> and a >> more complex flow. >> >> I wouldn't be surprised if this causes more initial setup, with the >> expectation this will be paid back by making building a complex design >> quicker. They probably aren't optimised for building very simple >> designs. >> >> Theo >> > I my case this is compared to a couple of revisions back but you are > right I'm currently using a Brevia 2, not a big FPGA, it the smallest > device in it's family, and I'm using less than half of the logic, in > some cases way less than half the logic. > > The wait has changed from 20 seconds or less to build the whole project > to several minutes making it an annoyance to have to build the entire > project. Still compared to using real hardware and changing the wiring, > which would make the project quite a difficult task to change, using a > FPGA is quite liberating. I know that the simulators are intentionally speed crippled to encourage users to upgrade to paid versions. I don't know if they do the same thing with synthesis tools or not. -- Rick CArticle: 159122
On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote: > Yes, these results do seem unreasonably bad. I'll try a different computer. I tried a different computer and got the same results.Article: 159123
On Friday, August 5, 2016 at 7:12:13 PM UTC+3, Kevin Neilson wrote: > On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote: > > Yes, these results do seem unreasonably bad. I'll try a different computer. > > I tried a different computer and got the same results. May be, two slow computers? Can you report specs?Article: 159124
On Sunday, August 7, 2016 at 2:14:48 AM UTC+3, already...@yahoo.com wrote:
> On Friday, August 5, 2016 at 7:12:13 PM UTC+3, Kevin Neilson wrote:
> > On Wednesday, August 3, 2016 at 10:51:18 AM UTC-6, Kevin Neilson wrote:
> > > Yes, these results do seem unreasonably bad. I'll try a different computer.
> >
> > I tried a different computer and got the same results.
>
> May be, two slow computers?
> Can you report specs?
In order to be sure that we are talking about the same thing I also created single-ff test case. Here are source/settings/project:
----- one_ff.vhd
library ieee;
use ieee.std_logic_1164.all;
entity one_ff is
port (
clk : in std_logic;
dout : out std_logic
);
end entity one_ff;
architecture a of one_ff is
signal ff : std_logic;
begin
process (clk)
begin
if rising_edge(clk) then
ff <= not ff;
end if;
end process;
dout <= ff;
end architecture a;
----- end of one_ff.vhd
---- one_ff.xdc
set_property IOSTANDARD LVCMOS25 [get_ports clk]
set_property IOSTANDARD LVCMOS25 [get_ports dout]
set_property PACKAGE_PIN L12 [get_ports clk]
set_property PACKAGE_PIN H12 [get_ports dout]
create_clock -period 10.0 -name clk [get_ports clk]
---- end of one_ff.xdc
---- one_ff.xpr
<?xml version="1.0" encoding="UTF-8"?>
<!-- Product Version: Vivado v2016.1 (64-bit) -->
<!-- -->
<!-- Copyright 1986-2016 Xilinx, Inc. All Rights Reserved. -->
<Project Version="7" Minor="12" Path="C:/xxx/one_ff.xpr">
<DefaultLaunch Dir="$PRUNDIR"/>
<Configuration>
<Option Name="Id" Val="0dc300cc961141dfa832739f8361bf18"/>
<Option Name="Part" Val="xc7z010iclg225-1L"/>
<Option Name="CompiledLibDir" Val="$PCACHEDIR/compile_simlib"/>
<Option Name="CompiledLibDirXSim" Val=""/>
<Option Name="TargetLanguage" Val="VHDL"/>
<Option Name="BoardPart" Val=""/>
<Option Name="ActiveSimSet" Val="sim_1"/>
<Option Name="DefaultLib" Val="xil_defaultlib"/>
<Option Name="EnableCoreContainer" Val="FALSE"/>
<Option Name="CreateRefXciForCoreContainers" Val="FALSE"/>
<Option Name="IPUserFilesDir" Val="$PPRDIR/one_ff.ip_user_files"/>
<Option Name="IPStaticSourceDir" Val="$PPRDIR/one_ff.ip_user_files/ipstatic"/>
<Option Name="EnableBDX" Val="FALSE"/>
<Option Name="WTXSimLaunchSim" Val="0"/>
<Option Name="WTModelSimLaunchSim" Val="0"/>
<Option Name="WTQuestaLaunchSim" Val="0"/>
<Option Name="WTIesLaunchSim" Val="0"/>
<Option Name="WTVcsLaunchSim" Val="0"/>
<Option Name="WTRivieraLaunchSim" Val="0"/>
<Option Name="WTActivehdlLaunchSim" Val="0"/>
<Option Name="WTXSimExportSim" Val="0"/>
<Option Name="WTModelSimExportSim" Val="0"/>
<Option Name="WTQuestaExportSim" Val="0"/>
<Option Name="WTIesExportSim" Val="0"/>
<Option Name="WTVcsExportSim" Val="0"/>
<Option Name="WTRivieraExportSim" Val="0"/>
<Option Name="WTActivehdlExportSim" Val="0"/>
<Option Name="GenerateIPUpgradeLog" Val="TRUE"/>
</Configuration>
<FileSets Version="1" Minor="31">
<FileSet Name="sources_1" Type="DesignSrcs" RelSrcDir="$PSRCDIR/sources_1">
<Filter Type="Srcs"/>
<File Path="$PPRDIR/one_ff.vhd">
<FileInfo>
<Attr Name="UsedIn" Val="synthesis"/>
<Attr Name="UsedIn" Val="simulation"/>
</FileInfo>
</File>
<Config>
<Option Name="DesignMode" Val="RTL"/>
<Option Name="TopModule" Val="one_ff"/>
<Option Name="TopAutoSet" Val="TRUE"/>
</Config>
</FileSet>
<FileSet Name="constrs_1" Type="Constrs" RelSrcDir="$PSRCDIR/constrs_1">
<Filter Type="Constrs"/>
<File Path="$PPRDIR/one_ff.xdc">
<FileInfo>
<Attr Name="UsedIn" Val="implementation"/>
</FileInfo>
</File>
<Config>
<Option Name="ConstrsType" Val="XDC"/>
</Config>
</FileSet>
<FileSet Name="sim_1" Type="SimulationSrcs" RelSrcDir="$PSRCDIR/sim_1">
<Filter Type="Srcs"/>
<Config>
<Option Name="DesignMode" Val="RTL"/>
<Option Name="TopModule" Val="one_ff"/>
<Option Name="TopLib" Val="xil_defaultlib"/>
<Option Name="TopAutoSet" Val="TRUE"/>
<Option Name="TransportPathDelay" Val="0"/>
<Option Name="TransportIntDelay" Val="0"/>
<Option Name="SrcSet" Val="sources_1"/>
</Config>
</FileSet>
</FileSets>
<Simulators>
<Simulator Name="XSim">
<Option Name="Description" Val="Vivado Simulator"/>
<Option Name="CompiledLib" Val="0"/>
</Simulator>
<Simulator Name="ModelSim">
<Option Name="Description" Val="ModelSim Simulator"/>
</Simulator>
<Simulator Name="Questa">
<Option Name="Description" Val="Questa Advanced Simulator"/>
</Simulator>
<Simulator Name="IES">
<Option Name="Description" Val="Incisive Enterprise Simulator (IES)"/>
</Simulator>
<Simulator Name="VCS">
<Option Name="Description" Val="Verilog Compiler Simulator (VCS)"/>
</Simulator>
<Simulator Name="Riviera">
<Option Name="Description" Val="Riviera-PRO Simulator"/>
</Simulator>
<Simulator Name="ActiveHDL">
<Option Name="Description" Val="Active-HDL Simulator"/>
</Simulator>
</Simulators>
<Runs Version="1" Minor="10">
<Run Id="synth_1" Type="Ft3:Synth" SrcSet="sources_1" Part="xc7z010iclg225-1L" ConstrsSet="constrs_1" Description="Vivado Synthesis Defaults" State="current" Dir="$PRUNDIR/synth_1" IncludeInArchive="true">
<Strategy Version="1" Minor="2">
<StratHandle Name="Vivado Synthesis Defaults" Flow="Vivado Synthesis 2016"/>
<Step Id="synth_design"/>
</Strategy>
<GeneratedRun Dir="$PRUNDIR" File="gen_run.xml"/>
</Run>
<Run Id="impl_1" Type="Ft2:EntireDesign" Part="xc7z010iclg225-1L" ConstrsSet="constrs_1" Description="Default settings for Implementation." State="current" Dir="$PRUNDIR/impl_1" SynthRun="synth_1" IncludeInArchive="true">
<Strategy Version="1" Minor="2">
<StratHandle Name="Vivado Implementation Defaults" Flow="Vivado Implementation 2016"/>
<Step Id="init_design"/>
<Step Id="opt_design"/>
<Step Id="power_opt_design"/>
<Step Id="place_design"/>
<Step Id="post_place_power_opt_design"/>
<Step Id="phys_opt_design"/>
<Step Id="route_design"/>
<Step Id="post_route_phys_opt_design"/>
<Step Id="write_bitstream"/>
</Strategy>
<GeneratedRun Dir="$PRUNDIR" File="gen_run.xml"/>
</Run>
</Runs>
</Project>
---- end of one_ff.xpr
According to my measurements synthesis took ~15s, implementation ~40s and write_bitstream ~20s. When launched together all three took ~65s.
Which is ridiculous, but somewhat less ridiculous than your results.
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