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
tullio wrote: > I answer to my own post, anyway the mismatch behavioral vs SynplifyPro > was simply due to the initilzation reset (GSR) that is applied only on > the post-Translate model (not on the behavioral model). > The mismatch behavioral vs XST remains and is probably one more bug of > XST that > i have no time to identify. > > tullio > > > tullio ha scritto: > >> We are designing a comunication system on a Spartan3 with a lot of data >> processing and buffering. >> We have several simulation mismatches: >> behavioral simulation gives results identical to Post-translate (with >> XST8.2.02 and option Keep Hierarchy: yes) >> But simulation of Post-translate with XST and option Keep Hierarchy >> off, gives different results; it's only a few different vectors over a >> thousand, but still unexplicable to me. >> We tried to compile with Synplify Pro, default settings; we did another >> post-translate simulation and the results are still different from all >> previous cases (again only a few vectors over a thousand). >> >> Any experience with that ? >> We paid attention to signed logic issues (see thread "behavioral vs >> post-P&R simulation mismatch" on Aug 30, 2006). >> We paid attention to crossing the clock domains. The clock structure >> is (in Verilog) >> >> ///////////////////////////////////////// >> ... >> input clk80, // 80 MHz clock. >> ... >> always @(posedge clk80) CE40 <= ~CE40; >> BUFG BUFG_clk40 (.O(clk40), .I(CE40)); >> >> ////////////////////////////////////////////////////// >> >> the reason for doing that, is we need a 40 MHz signal (CE40) to be used >> as an enable in the 80MHz domain. This signal must be in phase with >> clk40, and must not creates setup/hold violations when clocked by clk80 >> (this could happen using a DCM). > Have you tried instantiating the ROC element in your behavioural? This allows you to explicitly describe what GSR should be doing. The post-translate models get ROC added by the translator.Article: 109401
Weng Tianxiang wrote: ... > If you can list a graph that fails my algorithm, you beat me. I wish my algorithm design professor had taken that attitude. It would have made homeworks much easier. Instead, he insisted on proofs that my algorithms gave correct answers, as well as meeting their claimed time complexity. PatriciaArticle: 109402
james7uw@yahoo.ca wrote: > I suspect "Professional Edition" and "Special Edition", since, looking > at the comparison chart (compare.pdf) that can be found on the Xilinx > website (or maybe the ModelSim website at http://www.model.com), SE has > more features. I sure wish organizations would include glossaries or > acronym pages or FAQs to explain their acronyms. I complained directly > today via both the Xilinx and the ModelSim websites about that. > DUANWKWYM*. > > Cheers, > -James > > * "Don't Use Acronyms; Nobody Will Know What You Mean." > Artificially Contrived Reduction Of Names Yielding MnemonicsArticle: 109403
David Ashley wrote:
> Weng Tianxiang wrote:
> > Arthur J. O'Dwyer wrote:
> >
> >>On Sun, 24 Sep 2006, Weng Tianxiang wrote:
> >>
> >>>eKo1 wrote:
> >>>
> >>>>Let V' be a subset of V. V' is a vertex cover if it satisfies the
> >>>>following test:
> >>>>
> >>>>E' =3D =D8
> >>>>for each v in V'
> >>>> for each edge e in E
> >>>> if v is incident to e then
> >>>> add e to E'
> >>>> end if
> >>>> end for
> >>>>end for
> >>>>if |E| =3D |E'| then
> >>>> return true // V' is a vertex cover
> >>>>end if
> >>>>return false
> >>>>
> >>>>Would this be correct?
> >>>
> >>>Hi eKo1,
> >>>The algorithm you mentioned for a vertex cover is right.
> >>
> >> Yes, that's right. (And it suggests a trivial brute-force algorithm
> >>to find a minimum vertex cover:
> >>
> >> M =3D V
> >> for each V' in V
> >> if (V' is a vertex cover of G) then
> >> if |V'| < |M| then
> >> M =3D V
> >> end if
> >> end if
> >> end for
> >> return M
> >>
> >>Now M is a minimum vertex cover.)
> >>
> >>
> >>
> >>>Here is my full new algorithm that can get minimum vertex cover:
> >>>
> >>>To make discussion simpler, we assume that every vertex has a positive
> >>>integer, starting with 1 to n and input cells have the following
> >>>structure:
> >>>(edge count, edge starting vertex, edge ending vertexes).
> >>>
> >>>For example vertex 1 has edges: (1, 2), (1, 3), (1, 4), then its input
> >>>cell has the following representation: (3, 1, 2, 3, 4). Cell length
> >>>vary dependent on the cell's degree, or the number of edges which is
> >>>incident on the cell.
> >>
> >> Whoof, that's a clumsy representation! Next time, consider using a
> >>more natural representation, such as "Each vertex has a list of
> >>neighbors. For example, vertex 1 has neighbors {2,3,4}."
> >>
> >>
> >>>Here is new full algorithm to get minimum vertex cover:
> >>>1. Count =3D 0.
> >>>2. If input cell is empty, algorithm ends, otherwise
> >>> Sort the input cell serials based on count in increasing order.
> >>
> >> What are the "input cell serials"? I'm guessing you mean to sort the
> >>cells in increasing order by degree, i.e., the cells with lower degree
> >>come first in the list. Okay, but let me know if I'm wrong.
> >>
> >>
> >>>3. for all vertexes with edge count =3D 1, do following:
> >>> a. Set original starting vertex;
> >>
> >> What?
> >>
> >>
> >>> b. Count++;
> >>> c. Print out its edge ending vertex #; (only one)
> >>> d. Delete its input cell;
> >>> e. In the edge ending vertex cell, do the followings:
> >>> a. delete the original starting vertex in edge ending
> >>> vertexes area;
> >>
> >> What?
> >>
> >>
> >>> b. edge count is decreased by 1;
> >>> c. if edge count =3D 1, set current ending vertex as new
> >>> original starting vertex and go to b.
> >>> d. if edge count =3D 0, delete the cell;
> >>>4. If input cell is empty, algorithm ends, otherwise
> >>> sort the input cell serials based on count in decreasing order.
> >>
> >> What? What is the "input cell"? What is an "empty" cell --- is ()
> >>the only empty cell, or could (0, 5) be considered empty too?
> >>
> >>
> >>>5. If there is only one cell that has the largest degree, select the
> >>>cell
> >>> and go to 6. If there are more than one cell that have the equal
> >>> largest degree, select the cell that has not been the end vertex
> >>> of the last selected cell with the largest degree, or select any of
> >>>them
> >>> if all of them have have been the end vertexes of last selected cell
> >>
> >> What? What?
> >>
> >>(snip much more gibberish)
> >>
> >>
> >>>Manually I tried more than 20 graphs and get the right answers for
> >>>every graph.
> >>
> >> Good for you.
> >>
> >>
> >>>Do you have any smart tips?
> >>
> >> Yes. Stop trying to find a polynomial algorithm for minimum vertex
> >>cover until you've read at least one existing (non-polynomial) algorithm
> >>and understand how it works. Also, try to write in plain English, or,
> >>failing that, some common programming language.
> >>
> >>
> >>>If you can find a graph that fails the algorithm, please let me know.
> >>
> >> Yes, I can. So now you know.
> >>
> >>-Arthur
> >
> >
> > Hi Arthur,
> > I cannot read the page. Can you please post the page on the group or
> > send me an email?
> >
> > My email address is wtxwtx at gmail dot com (without space).
> >
> > I don't know if my algorithm is the same as the one you mentioned.
> >
> > Actually I checked my algorithm with more than 20 hand-drawn graphs and
> > all results generated are the minimum vertex cover, no exception!!!
> >
> > Otherwise I couldn't publish my 2nd version so quickly. If another
> > error is found, I can also quickly change my design to correct the
> > error without destroying the full design.
> >
> > The key point is:
> > 1. First delete all claws until there are no any claws; (Claw is a
> > vertex of degree 1).
> > 2. Next delete the vertex with largest degree and mark its neighbors to
> > keep them from being selected next time unless next time all vertexes
> > that have the largest degree are its neighbors. Later if a vertex's
> > edge is deleted, the vertex's neighbor mark should be deleted too if
> > any.
> > 3. Repeat 1. and 2. until all input cells are deleted.
> >
> > I will start writing a program in C and write some programs to generate
> > random graphs to check if there are any violations:
> > 1. Randomly generate a graph;
> > 2. Generate its minimum vertex cover, m=3D |V'| by my program.
> > 3. Check C(n, m-1) choices to see if any of them meets the minimum
> > vertex cover.
> >
> > I have "An introduction to Algorithm" written by Thomas H. Cormen etc.
> > It has a problem 35.1-3:
> > Professor Nixon proposes the following heuristic to solve the
> > vertex-cover problem. Repeatedly select a vertex of highest degree, and
> > remove all of its incident edges. Give an example to show that the
> > professor's heuristic doesn't not have an approximation ratio of 2.
> > (Hint: Try a bipartite graph with vertexes of uniform degree on the
> > left and vertexes of varying degree on the right. )
> >
> > That is exactly what I suggested in my first version. But with the
> > problem exposed, I changed my strategy to delete any claws first, then
> > do the selection.
> >
> > If you can post a graph that fails my algorithm, it will be great!!!
> >
> > Thank you.
> >
> > Weng
> >
>
> Weng,
>
> Did you mean to post this to comp.arch.fpga?
>
> It's an interesting problem and all, but...?
>
> -Dave
>
> --
> David Ashley http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture
Hi David,
Yes, I post it for comp.arch.fpga too.
1=2E comp.arch.fpga has a group of engineers who have many experiences
with logic design, are talent and should pay attention to the deepest
problem in computing complexity.
2=2E I dream someday we can design a NP machine that runs all NP problems
in polynomial time using a FPGA chip. Personally I think Turing machine
should be dying with powerful FPGA chips growing and the fact should be
reflected in computing theory.
3=2E The above posting is my a small step in a direction I am thinking is
right: first to design an algorithm that is not using brute force, but
some smart ideas of the special problem.
4=2E I select the minimum vertex cover because its memory will never be
expanded and it depends on a smarter selection to finish the cover.
5=2E At the current moment, I am devoting to design an algorithm that
works with minimum vertex cover.
6=2E If the algorithm works, all of us have a chance to finish a NP
machine with performance in polynomial time.
Thank you.
jWeng
Article: 109404Thank you for your answer. Unfortunately, the Hierarchy tab doesn't show me where each module is instantiated... (I'm talking about QuartusII 6.0sp1, I don't know if in the previous versions the Hierarchy tab was different). Maybe my explanation wasn't so good, so I will try to make an example: - suppose I have a design composed by 3 top-level blocks, named A, B and C (described as VHDL or schematic files); - suppose in each block I instantiated two 8-bit counter modules, all corresponding to a unique VHDL file (let's name it count8bit.vhd) In the Hierarchy tab I can expand one by one the tree under modules A, B and C and see that in each of them there are 2 instances of the "count8bit" entity. What I would like to do is the opposite: I'd like to select the count8.vhd module and see every instance of it in my design, so that I can locate the 2 instances in block A, the 2 in block B and the last 2 in block C. It would be very useful to me, I wonder if it's possible to do it with QuartusII because up to now I didn't find a way to do it. Regards, Claudio Sideway wrote: > Use the Hierarchy tab in the Project Navigator pane.Article: 109405
Patricia Shanahan wrote: > Weng Tianxiang wrote: > ... > > If you can list a graph that fails my algorithm, you beat me. > > I wish my algorithm design professor had taken that attitude. It would > have made homeworks much easier. Instead, he insisted on proofs that my > algorithms gave correct answers, as well as meeting their claimed time > complexity. > > Patricia Hi Patricia, 1. Yes, I have to prove the following theorem: If a graph has no claws (vertex of degree 1), the vertex with the largest degree can be a member of the minimum vertex cover. 2. I am doing the following things: a. Develop the algorithm in C; b. Develop an algorithm in C that can generate random graphs; c. Feed the graphs to my algorithm and generate |V'| data; d. Enumerate all cover options of C(N, |V'|-1) to confirm that there is no graph cover with less degrees. It takes time, but if all people help me, it will be great! Thank you. WengArticle: 109406
<james7uw@yahoo.ca> wrote in message news:1159245761.586819.18560@k70g2000cwa.googlegroups.com... > Handy link for this entire thread: > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6 > > > "input setup/hold time" is the time required before a clock edge to > setup and hold an input signal so that the receiving FF will > successfully register it, is that right? Yes, almost. Setup time is the time for the signal to be stable prior to the clock. Hold time is the time for the signal to be stable after the clock (many times, but not always hold time is 0). > > I am using the "Test Bench WaveForm" GUI feature (Xilinx ISE ver > 8.2.03i, now) and in the clock timing input window that comes up > automatically when I create a tbw file, there are settings for "Input > setup time" and "output valid delay", that I have to fill in. "Input > setup time" is the time duration that the testbench will place my input > signal transitions before its clock edges, is that right? Yes > For example, > I have a "load" pulse that I draw in the GUI and the testbench will > make sure to activate its edges 1ns before the matching clock edges if > I set "input setup time" to 1ns, is that right? Yes > Does "output valid > delay" mean the time duration after a clock edge at which output data > becomes valid? If so, I don't understand what that tells the testbench > to do. Since that seems to be dependent upon the device under test and > yet it is a testbench entry parameter, I am confused as to the meaning > of that and must be understanding it wrong. Sort of. What you're telling the testbench is how long it is before the outputs of your design will become valid so that it doesn't bother to check them prior to that time. You're right that this is dependent on the device under test but so is the input setup times that you're entering. Generally what you would put into the testbench for these are numbers that you 'can live with' in your actual design. By that I mean, the FPGA doesn't usually live in isolation it is connected to outside devices that may have timing requirements as well. For example, if one of the inputs to the FPGA is connected to some device that has Tco = 10 ns and that part and the FPGA both transmit/receive this signal with the same 10MHz clock (i.e. T=100 ns). Then as a first order approximation one could calculate the input setup time requirement at the FPGA as being T-Tco = 90 ns. A more accurate approximation would be to realize that there is going to be clock skew between the two devices and delay on the printed circuit board that will eat into that timing margin and you should take those into consideration as you define what the FPGA input setup requirements are. The point is you probably wouldn't want to put the 90ns in as the FPGA's requirement, get some estimates for those other two or swag them as being less than 5 ns or so and enter 85 ns. For a really high speed design you'll be more careful about determining the things that go into the timing budget for the simple reason that there is less time per clock cycle and you can't afford to not have better control over everything. Anyway, whatever that input setup time requirement is that you determine should go two places: as a constraint to the fitter that it needs to meet and into your testbench. Also note that the requirement is determined without regard to any timing numbers from the FPGA itself. It is a requirement that is determined by the outside world around the FPGA. Most people do go through some form of this figuring out and enter the number into the fitter so that when the timing analysis is performed it clearly flags violations. What most do not do is to enter that exact same requirement into the testbench. Repeat this process for computing what the clock to output delay requirement of the FPGA is. Here you would start with your clock period and subtract off the input setup time of whatever device is on the receiving end of the FPGA output, subtract off clock skew, subtract off PCB delay. The basic process is the same. > > So I have to make sure that my "Input setup time" that I specify has > got to satisfy all input setup/hold times required by the mapper timing > report, is that right? What do I look at to specify the "output valid > delay" (it must be some kind of data in the timing report. I'll take a > look)? Does that mean I'm telling the testbench not to "look" at data > before that time period after a clock pulse just for reporting and > display purposes? See above for the more detailed answer. > > I am synthesizing and translating and getting correct operation in > simulation but then mapping and getting incorrect operation -- I have > an initial load into a submodule of 128 bits and a simple subsequent > output from the submodule of that separated into its four 32-bit words. > In that, post-map, the lower three bytes of the second register are > being duplicated into the third register, both in the signals used in > the calling module and in the signals used in the submodule. It looks > like logic is getting optimized away incorrectly, but could that really > be happening by violating setup and hold times in the testbench? > Don't know. Just as with real life, when you violate timing requirements pretty much anything might happen. It would depend totally on the actual implementation. If that's what it's doing, then that's what it's doing. > I am getting seven warnings of the following type from ModelSim when it > does post-map simulation: > # ** Warning: /X_SFF SETUP High VIOLATION ON CE WITH RESPECT TO CLK; > # Expected := 0.74 ns; Observed := 0.583 ns; At : 291.975 ns > # Time: 291975 ps Iteration: 3 Instance: > /user_logic_tb/uut/slv_reg0_7 > Is that just a slight difference as compared to the behavioral > simulation? I think that the simulator compares results, is that right? The simulator calls it a warning but it really is a design error. What exactly the simulation model does when this occurs is a function of how the simulation model is coded. Best to investigate why the logic path is long and clean up those problems now. If all of the timing violations are setup times, you can temporarily code around this simply by slowing down your clock for simulation. Get the testbench to the point that it can run the original source and the post-map model with no reported timing errors. The more thorough check though is to compare the timing requirements that you have in your testbench with what pops out of the timing analysis report. The reason it is more thorough is that your simulation might not happen to hit every input under just the right conditions. Bottom line is that if you've determined that the input setup requirement is 15 ns then the timing report had better report something less than 15 ns in the actual implementation or you have a design issue to resolve. Timing analysis does not require any simulation. Do this for all inputs and outputs. > > To clarify what was meant by levels of logic, here is what the Xilinx > tech support engineer wrote: > > ----------------------------- > I looked at your code and I have some suggestions for you. You have > registered your design, but you haven't pipelined the design which will > more or less fix the issue you are having. What you did was place a > register on the output, but the output is not being optimized, the > combinational logic in-between is. This is what needs to be > registered. In one example of your code you have 4 logic levels. > > w2(31 downto 24) <= wsav0(31 downto 24) xor wsav2(31 downto 24) xor > wsav1(31 downto 24) xor subwordsav(31 downto 24) xor rconsav; > > In a fully pipelined design, you would only have one logic level per > register. Meaning you will xor two signals, register it and then xor > it with the next, register it and so on. This should fix your problem. > Map is optimizing all your combinational logic in look-up tables (LUTs) > and its removing the duplicate XOR gates. Placing the registers > between the logic levels will stop that. > > In regards to your other questions, due to the tools behaving correctly > [THAT HAS NOT BEEN ESTABLISHED], this has become a design issue and no > longer a support issue. Unfortunately, the technical support team > doesn't have the resources to help you further with your case. We do > have other options available though. If you go to the Design and > Education Services page (linked below) there are a couple of options in > which you can get help. > > http://www.xilinx.com/support/gsd/ > > We have the Titanium Engineering group as well as Xilinx Design > Services. This is in addition to possible help from the local FAE. > I'm sorry I am no longer able to help you with your issues, but I hope > my information has pointed you in the right direction toward solving > your problem. > > I will go ahead and close this case; if you have any other support > issues please open another Webcase and our team will be happy to assist > you. > ----------------------------- The problem as I see it is that the original source and the post-map simulation models don't agree. I don't see anything in the response from Xilinx to address this but maybe you didn't word it in exactly that manner. Once you get your timing errors cleaned up you should have a testbench that will provide the identical stimulus to both models. If they still perform differently then open another service request to Xilinx (or your FAE) and have them explain why the two are different. It has absolutely nothing to do with optomizations. Original source and post-anything must be functionally identical...regardless of what the function actually is. Stick to your guns on that and don't let them off the hook but also don't sidetrack them with optomization settings or any of that. It is the software's job to translate your code into something functionally identical that they can actually implement inside a real device. Just make sure you've cleaned up all timing problems before since that is on your side, not theirs. > > I did the above suggestion and my job of combining only pairs of > signals at a time at alternate clock edges was a work of art, but it > produced the exact same results. > > I have produced screenshots of the simulations that show correct > operation in behavioral and the flaw in post-map and sent that to > Xilinx. The way I worded it was to ask for the correct VHDL coding > style to prevent that kind of optimization and I complained about > undocumented mapper coding requirements. So now the problem doesn't > look like VHDL coding style any more. Other than things I've mentioned earlier in the thread about incorrectly using things other than std_logic/std_ulogic or latches or things like that it never is coding 'style' per se. So do the timing analysis, verify that the testbench presents inputs and checks outputs at the appropriate time per your requirements then re-collect the screen shots and send it off and ask them to explain the difference since they are supposed to be functionally identical. > A while ago I removed my one boolean signal and replaced it with > std_logic that I can test in "if" statements just as well, so I haven't > had anything but std_logic in my design during the last couple of weeks > or so. Good, one less thing to worry about right now. The reason std_logic is such a good thing is simply because of the value 'X'. Being able to get rid of all the unknowns in a simulation is a milestone of sorts and when you can't for whatever reason then that big 'X' is staring at you pointing you right to the place to investigate. Anyway, you don't have that but just thought I'd toss out why using only std_logic is a 'good' thing until you've been doing this for a while and can move on with confidence to other types. > > I'm getting back to Xilinx and I'll try your approach of getting them > to explain what is going on, use your wording, and try not to accept > anything less than working with me until the issue is solved. > Good plan. > What is that post-map design file that I can look at? I do have six > unconnected signals being reported as nets that have no load in the map > report, but the FAE (Field Application Engineer) says he never has any > problems with that type of thing. However, he agrees that it wouldn't > hurt to look at the "Technology Schematic", produced post-translate, > identify those nets that map is complaining about and see if they are > actually intended to have loads (I thought everything in my design is > connected up). That's what I'm going to do next, now that I've removed > a bunch of VHDL code that doesn't change anything and just adds > complexity. It shouldn't be a problem and if it is it's Xilinx's problem anyway. Remember your original source code is not the actual implementation it is an abstraction. FPGAs do not implement 'a xor b' they translate that into a lookup table that has been programmed appropriately and enable pass transistors to get signals 'a' and 'b' to the proper inputs to that table. Sometimes warnings can point to problems but in this case I don't think it will but like the FAE said, it wouldn't hurt to look either. I'm not exactly sure at what file you need to look at though. Maybe try searching through all of the files for the net name that is being flagged and see what hits. KJArticle: 109407
Hi I'm making a design in a FPGA for a colour STN LCD. The display is up and running in the 8 basic colours , RGB. We would like to achieve 4096 colours by modulating the 3 primary colour bits over 16 frames (and then use 256 of them). The display seems to flicker when we tries to LPM modulate. Have any one tried this or have any ideas how to make "gray" scales on the LCD. Best regards, FredrikArticle: 109408
Lathi.Tan@gmail.com wrote: > Thank you all. I haven't tried it yet, but it must be the solution. > Will let you know when the problem is fixed. > > Lathi One more thing... In the Xilinx tools there are two different constraints that control Finite State Machine encoding: FSM_ENCODING and SIGNAL_ENCODING In my experience you need to set both of these to "user" in order to end up with user encoded logic after mapping. It may be worth checking if your translated design is really binary encoded and not forced to one-hot somewhere farther along the tool chain. HTH, GaborArticle: 109409
Stefan Tillich wrote: > Hi, > > I'm investigating the possibility to replace an Spartan-2E (xc2s400e) > with an Spartan-3E (xc3s1200e) device on a PCB. > > The core voltage drops from 1.8V to 1.2V. Has anyone experience > regarding the footprint differences (easy/hard/impossible to adapt) and > any other differences which must be taken into account? > > Regards, > > Stefan The footprint is different; beyond that, all parts can be routed. As noted with the S3 vs S3E thread 2 days ago, there are a couple "gotchas" that you need to be aware of. There are only 4 IO banks, not 8. While not necessarily a "problem" your existing design might dedicate eighths of the chip to a specific VCCIO rather than even quarters. Also, many of the S3E IOBs are input-only to save on die size; while this is fine for many, the loss of flexibility is felt. I wouldn't expect the redesign to be a problem, otherwise. I think S2 had tristate buffers but not S2E; either way, S3 and S3E don't have them. Memory blocks are now larger and DLLs are more functional as DCMs, both have "compatibility modes" for older designs. There's no longer a power-on surge. You also have new, cheaper programming ROM options. I hope the conversion is fun.Article: 109410
Weng Tianxiang wrote: > David Ashley wrote: >> Weng Tianxiang wrote: >>> >> Weng, >> >> Did you mean to post this to comp.arch.fpga? >> >> It's an interesting problem and all, but...? >> >> -Dave >> >> -- >> David Ashley http://www.xdr.com/dash >> Embedded linux, device drivers, system architecture > > Hi David, > Yes, I post it for comp.arch.fpga too. > > 1. comp.arch.fpga has a group of engineers who have many experiences > with logic design, are talent and should pay attention to the deepest > problem in computing complexity. > > 2. I dream someday we can design a NP machine that runs all NP problems > in polynomial time using a FPGA chip. Personally I think Turing machine > should be dying with powerful FPGA chips growing and the fact should be > reflected in computing theory. > > 3. The above posting is my a small step in a direction I am thinking is > right: first to design an algorithm that is not using brute force, but > some smart ideas of the special problem. > > 4. I select the minimum vertex cover because its memory will never be > expanded and it depends on a smarter selection to finish the cover. > > 5. At the current moment, I am devoting to design an algorithm that > works with minimum vertex cover. > > 6. If the algorithm works, all of us have a chance to finish a NP > machine with performance in polynomial time. > > Thank you. > > jWeng If you had an amazing vacation planned and you knew the best way to travel was by car and that car enthusiasts were very knowledgeable about traveling, would you post about the vacation to an automotive design bulletin board?Article: 109411
does anybody uses partitions in Xilinx tools by command line? It seem they are available only in project navigator or in tcl environment. I ask if it is possible to use them in a UNIX command line like bash. Thank youArticle: 109412
Weng Tianxiang wrote: > 1. comp.arch.fpga has a group of engineers who have many experiences > with logic design, are talent and should pay attention to the deepest > problem in computing complexity. > > 2. I dream someday we can design a NP machine that runs all NP problems > in polynomial time using a FPGA chip. Personally I think Turing machine > should be dying with powerful FPGA chips growing and the fact should be > reflected in computing theory. >... I understand your goal + hope you make progress. I've read that all NP Complete problems can be mapped onto each other, so that if you can solve one in faster than exponential time, you can solve them all. My personal feeling is throwing an fpga at the problem is akin to throwing more computers at it. FPGA's grow in 2D though. Even if you could pack computers together in 3D, the complexity of the problems is such that time to solve them will grow faster than you can expand your 3D matrix of computing fabric. It's hopeless... What interesting problems would you want to solve in polynomial time, anyway? The vertex coverage one doesn't have in itself any useful application in my life. Perhaps protein folding? AI in some way? Place + Route? Speaking of which, here's a nobel prize winning idea. Assuming the problem of protein folding is part of NP complete, all you'd have to do is construct a DNA sequence that encodes for a protein, and the protein itself is equivalent to some OTHER NP problem you want to solve. So you let the protein go and fold however it wants to, and then you look at how it's folded, and you have your answer. So you've managed to get the universe to work for you. :) Sorry for adding to this off-topic mayhem. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109413
I am searching for a new topic related to FPGAs and that is publishable? Any ideas? I was thinking of area, performance, speed and interconnection optimization. Please provide me with some interesting ideas and I will do the rest of the work. Thanks!Article: 109414
solo wrote: > I am searching for a new topic related to FPGAs and that is > publishable? > Any ideas? > I was thinking of area, performance, speed and interconnection > optimization. Please provide me with some interesting ideas and I will > do the rest of the work. > Thanks! > Any improvements that can be made in the place + route burden would be publishable, as well as make you $$$. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109415
Hey Dave, Can you be more specific in your advice please? Thanks! David Ashley wrote: > solo wrote: > > I am searching for a new topic related to FPGAs and that is > > publishable? > > Any ideas? > > I was thinking of area, performance, speed and interconnection > > optimization. Please provide me with some interesting ideas and I will > > do the rest of the work. > > Thanks! > > > > Any improvements that can be made in the place + route > burden would be publishable, as well as make you $$$. > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architectureArticle: 109416
I think I know, what you mean. Qaurtus shows the instances in the h-tab, but when clicking on it, Q jumps to the module. I do it that way, that I use cut&paste to copy the name of the module, jump to the former folder (upper level) and do a search for. Another possibilty is to click on the item and chooes "Locate in design"Article: 109417
Let G be a tree of height h > 0. Say the root is at the level 0 of the tree, its children at level 1, their children at level 2, etc.. If h is odd, let V' be the set of vertices at the even levels of the tree. If h is even, let V' be the set of vertices at the odd levels of the tree. Is V' a minimum vertex cover?Article: 109418
Stefan Tillich <stefanti@NOSPAMgmx.at> wrote: >Hi, > >I'm investigating the possibility to replace an Spartan-2E (xc2s400e) >with an Spartan-3E (xc3s1200e) device on a PCB. > >The core voltage drops from 1.8V to 1.2V. Has anyone experience >regarding the footprint differences (easy/hard/impossible to adapt) and >any other differences which must be taken into account? The blockrams in the S3 are bigger and S3 does not have tristate busses. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 109419
David Ashley wrote: > Weng Tianxiang wrote: > > 1. comp.arch.fpga has a group of engineers who have many experiences > > with logic design, are talent and should pay attention to the deepest > > problem in computing complexity. > > > > 2. I dream someday we can design a NP machine that runs all NP problems > > in polynomial time using a FPGA chip. Personally I think Turing machine > > should be dying with powerful FPGA chips growing and the fact should be > > reflected in computing theory. > >... > > I understand your goal + hope you make progress. I've read > that all NP Complete problems can be mapped onto each > other, so that if you can solve one in faster than exponential > time, you can solve them all. > > My personal feeling is throwing an fpga at the problem is > akin to throwing more computers at it. FPGA's grow in > 2D though. Even if you could pack computers together > in 3D, the complexity of the problems is such that time to > solve them will grow faster than you can expand your 3D > matrix of computing fabric. It's hopeless... > > What interesting problems would you want to solve in > polynomial time, anyway? The vertex coverage one doesn't > have in itself any useful application in my life. Perhaps > protein folding? AI in some way? Place + Route? > > Speaking of which, here's a nobel prize winning idea. > Assuming the problem of protein folding is part of NP > complete, all you'd have to do is construct a DNA > sequence that encodes for a protein, and the protein > itself is equivalent to some OTHER NP problem you > want to solve. So you let the protein go and fold however > it wants to, and then you look at how it's folded, and you > have your answer. So you've managed to get the universe > to work for you. :) > > Sorry for adding to this off-topic mayhem. > > -Dave > > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture Hi David, The idea I tried to attack the minimum vertex cover has nothing to do with its range of applications. Far beyond that, because all NP problems are the same in computing complexity, I choose the simplest one in concept and tried to attack it. If it could be resolved in polynomial time, every other problem in NP class could be resolved too. The minimum vertex cover is so simple that my algorithm lives only one day and is dead now with a persuasive counterexample raised by Patricia. I have to read Cook's original paper once more. Thank you, masters Cook and Karp, you had raised an open question for all human to answer. WengArticle: 109420
Link to this entire thread: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/61c7e513258e54ea/c9305826ce4b4247#c9305826ce4b4247 I received a reply from Mentor Graphics, but not from Xilinx: ---------------------------------------------- Hi James, Here is the breakdown on the ModelSim offerings: ModelSim SE - Special Edition ModelSim LE - Linux Edition ModelSim PE - Personal Edition I'll work on getting these added to our product pages. Thank you for the feedback. Best Regards, Bill Guthrie Mentor GraphicsArticle: 109421
[followups set to comp.programming only]
On Tue, 26 Sep 2006, eKo1 wrote:
>
> Let G be a tree of height h > 0. Say the root is at the level 0 of the
> tree, its children at level 1, their children at level 2, etc.. If h is
> odd, let V' be the set of vertices at the even levels of the tree. If h
> is even, let V' be the set of vertices at the odd levels of the tree.
> Is V' a minimum vertex cover?
No. Consider
4-----9-----11--12
| | |
2--3 7--8 10
| |
1 6
where 4 is the root. Your algorithm gives (4, 1, 3, 6, 8, 11) where the
real solution --- which can be found using the optimal "claw-removal"
part of the OP's algorithm, since it always works as long as you never
run out of claws --- is (4, 2, 6, 8, 11).
As Mark P, Patricia, and I have pointed out, and I think Weng finally
acknowledged, the problem with his algorithm is not with the "claw
removal" but with the fallback greedy algorithm. The solution is to
replace the fallback greedy algorithm with a fallback brute-force
algorithm.
-Arthur
Article: 109422David Ashley wrote: ... > What interesting problems would you want to solve in > polynomial time, anyway? The vertex coverage one doesn't > have in itself any useful application in my life. ... Suppose you have a set of nodes (computers, switches, memory modules...) with point-to-point links between them, and want to instrument the smallest possible subset of the nodes such that you can monitor traffic on each point-to-point link. PatriciaArticle: 109423
"Roger" <enquiries@rwconcepts.co.uk> wrote in message news:... > > "Roger" <enquiries@rwconcepts.co.uk> wrote in message > news:4516e3e1$0$3616$ed2e19e4@ptn-nntp-reader04.plus.net... >> I'm having trouble getting some lines in a UCF file to be accepted by >> ISE. The lines are: >> >> NET Inst_rio_fo2_top/aurora_module_i/lane_0_mgt_i/RXRECCLK PERIOD=6.4 ns; >> NET Inst_rio_fo2_top/user_clk_i PERIOD = 6.4 ns HIGH 50 %; >> INST >> Inst_rio_fo2_top/aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* >> AREA_GROUP="PHASE_ALIGN_FO2_GRP"; >> AREA_GROUP "PHASE_ALIGN_FO2_GRP" RANGE=SLICE_X26Y72:SLICE_X27Y73; >> INST Inst_rio_fo2_top/aurora_module_i/lane_0_mgt_i LOC=GT_X1Y1; >> >> which is for an Aurora core on a 2VP7. Much of this is copied from the >> sample Aurora stuff generated by the Core Generator. Has anyone else had >> any issues with this or can anyone see anything obvious. The error occurs >> on the >> >> INST >> Inst_rio_fo2_top/aurora_module_i/lane_0_phase_align_i/phase_align_flops_r* >> AREA_GROUP="PHASE_ALIGN_FO2_GRP"; >> >> line when it's claimed it could not find the instance of the phase align >> flops but which are definitely there. >> >> TIA, >> >> Rog. >> > It seems that the lines in lane_0_phase_align_i (phase_align.vhd) : attribute KEEP_HIERARCHY:string; attribute KEEP_HIERARCHY of RTL: architecture is "true"; are the source of trouble. If these are comented, the Translate process runs OK. Does anyone know what's going on here? Thanks, Rog.Article: 109424
Hi group This must sound like a dumb question. How can I update from ISE and EDK 8.1 to 8.2? I downlaoded and installed the available patches for 8.1 and there are patches available for 8.2 but I can't see an option / way to actually update 8.1 into 8.2. Do I just have to downlaod and install the 8.2 patches (haven't tried this since I'm afraid to screw things up). Is there another way? TIA Markus
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