Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 109400

Article: 109400
Subject: Re: simulation mismatch (xilinx)
From: David R Brooks <davebXXX@iinet.net.au>
Date: Tue, 26 Sep 2006 01:54:17 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: An algorithm with Minimum vertex cover without considering its
From: Patricia Shanahan <pats@acm.org>
Date: Tue, 26 Sep 2006 09:57:12 GMT
Links: << >>  << T >>  << A >>
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

Article: 109402
Subject: Re: Does anyone know what "SE" and "PE" stand for in ModelSim?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Tue, 26 Sep 2006 01:58:33 -0800
Links: << >>  << T >>  << A >>
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
Mnemonics


Article: 109403
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 26 Sep 2006 03:05:46 -0700
Links: << >>  << T >>  << A >>

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: 109404
Subject: Re: QuartusII: how to find out all the instances of a VHDL module in a design?
From: "Claudio" <Totti10@hotmail.com>
Date: 26 Sep 2006 03:19:04 -0700
Links: << >>  << T >>  << A >>
Thank 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
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 26 Sep 2006 03:19:51 -0700
Links: << >>  << T >>  << A >>

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.

Weng


Article: 109406
Subject: Re: Now on 8.2.03i Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!
From: "KJ" <kkjennings@sbcglobal.net>
Date: Tue, 26 Sep 2006 10:44:04 GMT
Links: << >>  << T >>  << A >>

<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.

KJ 



Article: 109407
Subject: LCD(STN) controller
From: "frka" <fredrik.karlsson@prevas.se>
Date: 26 Sep 2006 05:41:18 -0700
Links: << >>  << T >>  << A >>
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,

Fredrik


Article: 109408
Subject: Re: state machine dead problem
From: "Gabor" <gabor@alacron.com>
Date: 26 Sep 2006 06:29:55 -0700
Links: << >>  << T >>  << A >>

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,
Gabor


Article: 109409
Subject: Re: Migration from Spartan-2E to Spartan-3E
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 26 Sep 2006 13:37:00 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: An algorithm with Minimum vertex cover without considering its
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 26 Sep 2006 13:42:02 GMT
Links: << >>  << T >>  << A >>
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
Subject: ise 8.2 partitions
From: antonio bergnoli <bergnoli@pd.infn.it>
Date: 26 Sep 2006 16:58:31 +0200
Links: << >>  << T >>  << A >>
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 you

Article: 109412
Subject: Re: An algorithm with Minimum vertex cover without considering its
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 26 Sep 2006 08:01:57 -0700
Links: << >>  << T >>  << A >>
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

Article: 109413
Subject: PUBLISHABLE PAPER RELATED TO FPGA!
From: "solo" <alexandre.aoun@gmail.com>
Date: 26 Sep 2006 08:02:10 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: PUBLISHABLE PAPER RELATED TO FPGA!
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: Tue, 26 Sep 2006 08:04:50 -0700
Links: << >>  << T >>  << A >>
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 architecture

Article: 109415
Subject: Re: PUBLISHABLE PAPER RELATED TO FPGA!
From: "solo" <alexandre.aoun@gmail.com>
Date: 26 Sep 2006 08:14:09 -0700
Links: << >>  << T >>  << A >>
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 architecture


Article: 109416
Subject: Re: QuartusII: how to find out all the instances of a VHDL module in a design?
From: "alterauser" <fpgaengineerfrankfurt@arcor.de>
Date: 26 Sep 2006 09:00:28 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "eKo1" <berndlosert@netscape.net>
Date: 26 Sep 2006 09:10:52 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Migration from Spartan-2E to Spartan-3E
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 26 Sep 2006 16:14:24 GMT
Links: << >>  << T >>  << A >>
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.nl

Article: 109419
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 26 Sep 2006 09:40:07 -0700
Links: << >>  << T >>  << A >>

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.

Weng


Article: 109420
Subject: Re: Does anyone know what "SE" and "PE" stand for in ModelSim?
From: james7uw@yahoo.ca
Date: 26 Sep 2006 09:40:59 -0700
Links: << >>  << T >>  << A >>
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 Graphics


Article: 109421
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "Arthur J. O'Dwyer" <ajonospam@andrew.cmu.edu>
Date: Tue, 26 Sep 2006 12:50:46 -0400 (EDT)
Links: << >>  << T >>  << A >>

[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: 109422
Subject: Re: An algorithm with Minimum vertex cover without considering its
From: Patricia Shanahan <pats@acm.org>
Date: Tue, 26 Sep 2006 16:58:18 GMT
Links: << >>  << T >>  << A >>
David 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.

Patricia

Article: 109423
Subject: Re: Aurora UCF problem
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Tue, 26 Sep 2006 18:08:52 +0100
Links: << >>  << T >>  << A >>
"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
Subject: Newbee question - how to upgrade to Xilinx ISE/EDK 8.2 from 8.1
From: Markus Zingg <m.zingg@nct.ch>
Date: Tue, 26 Sep 2006 19:53:47 +0200
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search