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 May 3, 3:49 am, "Ken Soon" <c...@xilinx.com> wrote: > Hi > Just want to do a feasibility study on whether it is possible to design and > implement a video scaler on a Spartan 3E? > Well my tutor kind of came up with this proposal for a project of mine but > then on my tutor's side, he has experience with fpga but I'm not sure > whether he had designed video scaling so may not know the complexity of it. > > So, feasible? And with which chip as well? (in the best of best case, i hope > can use just a spartan starter kit :) ) For that you need to sample a 250kB image into RAM and read it back in a different order. You need to do that 25 or 30 times a second. As long as you have 500kB of SRAM that can handle 16MB/S random access this should be easy. For better results you need to interpolate multiple pixels on readback which increases the bandwidth requirement. Rotating the image requires not much more hardware than scaling. Both is done with two bresenham units. Kolja SulimmaArticle: 118751
On 3 Mai, 03:49, "Ken Soon" <c...@xilinx.com> wrote: > Hi > Just want to do a feasibility study on whether it is possible to design and > implement a video scaler on a Spartan 3E? > Well my tutor kind of came up with this proposal for a project of mine but > then on my tutor's side, he has experience with fpga but I'm not sure > whether he had designed video scaling so may not know the complexity of it. > > So, feasible? And with which chip as well? (in the best of best case, i hope > can use just a spartan starter kit :) ) as a starter you may look at "rotazoom" IP included in demo designs of spartan-3A kit. it takes bitmap image from memory and display it zoomed and rotated on display. AnttiArticle: 118752
Hi, I build a PLB Master in single byte transfer mode and it works well. Now, I try to use the burst mode and I don't understand something. For a burst transaction, at each rising edge of the clk, a new data and a new address is presented to a peripheral. I use the plb ipic and what I don't understand is in the state machine : Normaly, at each rising edge of the clk, the state machine had to increase my ip2ip and ip2bus address to make a burst transaction. But in fact, in the Last_Burst state, the state machine wait the Bus2IP_MstLastAck=1 to increase it. The problem is that the Bus2IP_MstLastAck is not still active. Why ? If is not still active, how can I build a burst transaction ???? Thanks !Article: 118753
> Question:: is there a limitation in terms of "clock cycles" to hold > the M_Select/M_Buslock high when given OPB_Mgrant by the opb BUS. There is a timeout for OPB transfers (see ToutSup signal). Maybe this is what you are looking for? MarcArticle: 118754
On a sunny day (3 May 2007 01:20:54 -0700) it happened "comp.arch.fpga" <ksulimma@googlemail.com> wrote in <1178180454.117412.95440@h2g2000hsg.googlegroups.com>: >On May 3, 3:49 am, "Ken Soon" <c...@xilinx.com> wrote: >> Hi >> Just want to do a feasibility study on whether it is possible to design and >> implement a video scaler on a Spartan 3E? >> Well my tutor kind of came up with this proposal for a project of mine but >> then on my tutor's side, he has experience with fpga but I'm not sure >> whether he had designed video scaling so may not know the complexity of it. >> >> So, feasible? And with which chip as well? (in the best of best case, i hope >> can use just a spartan starter kit :) ) > > >For that you need to sample a 250kB image into RAM and read it back in >a different order. >You need to do that 25 or 30 times a second. >As long as you have 500kB of SRAM that can handle 16MB/S random access >this should be easy. >For better results you need to interpolate multiple pixels on readback >which increases the bandwidth >requirement. >Rotating the image requires not much more hardware than scaling. Both >is done with two bresenham units. > >Kolja Sulimma I dunno, I think you can do that with much less memory, say we scale 1 to 2, then you only need to strore 2 picture lines of the original: ABCDEFG HIJKLMN Now you start averaging first pixel out = (A+B+H+I) / 4, second pixel out = (B+C+I+J) / 4. etc, In this case you only need to store 2 lines. For other factors you need some more lines. Do not forget the aliasing factor, you are sub sampling, and need to lowpass at below f/2.Article: 118755
"LilacSkin" <lpaulo07@iseb.fr> wrote in message
news:1178185843.656412.22790@p77g2000hsh.googlegroups.com...
> Hi,
> For a burst transaction, at each rising edge of the clk, a new data
> and a new address is presented to a peripheral.
Not true. The first address is presented in the initial "address" phase of
the transaction. The slave is responsible for calculating all subsequent
addresses after that.
> I use the plb ipic and what I don't understand is in the state
> machine :
I guess you mean the IPIF... I don't know anything about that so I can't
help you there. But it's often just as easy (if not easier) just to drive
the PLB signals yourself, directly. There have been quite a few threads on
this subject here recently.
Cheers,
-Ben-
Article: 118756On 3 mai, 12:17, "Ben Jones" <ben.jo...@xilinx.com> wrote: > "LilacSkin" <lpaul...@iseb.fr> wrote in message > > news:1178185843.656412.22790@p77g2000hsh.googlegroups.com... > > > Hi, > > For a burst transaction, at each rising edge of the clk, a new data > > and a new address is presented to a peripheral. > > Not true. The first address is presented in the initial "address" phase of > the transaction. The slave is responsible for calculating all subsequent > addresses after that. > > > I use the plb ipic and what I don't understand is in the state > > machine : > > I guess you mean the IPIF... I don't know anything about that so I can't > help you there. But it's often just as easy (if not easier) just to drive > the PLB signals yourself, directly. There have been quite a few threads on > this subject here recently. > > Cheers, > > -Ben- Sorry I don't have time to drive directly the PLB signals. I just want to build a burst transaction. You say that "The slave is responsible for calculating all subsequent addresses after that." I agree with you, but I need to present a data to the slave component. So I had to count my ip2ip adress in order to present the data from my slaves registers of my slave/master component to the slave component. Are you agree ?Article: 118757
Hello. I'm new to FPGA desing, so could you please help me with this little = problem. To run my sensor I must have some delays in communication with it = (DS18B20). When I put this into my code "wait for 500 us;" I get --> parse error, unexpected WAIT I tried to desing a down counter with set and reset, and used wait until= = "count=3D0" but I get the same error. Here is a simple example. **************** architecture Behavioral of ispis is begin = DQ <=3D '0'; wait for 500 us; End Behavioral; **************** How to program delays for my code if "wait" wont work? Maybe I'm using i= t = in the wrong way? Thanks.Article: 118758
On 2007-05-03, Andy <jonesandy@comcast.net> wrote:
> You cannot wait for TIME in synthesizable code. You can wait until
> rising_edge(clk)! Not usually the best coding style, but it can be
> done and is accepted by most synthesis tools.
I was also of the opinion that it wasn't a very good coding style but
after a couple of years of basic VHDL teaching I think it is actually
better to say that a sequential process looks like this:
process
begin -- process
wait until rising_edge(clk);
-- Some code...
end process;
The "standard" alternative is this:
process (clk)
begin -- process
if clk'event and clk = '1' then -- rising clock edge
-- Some code...
end if;
end process;
The problem with the second one is that first time students are likely
to produce something like:
process (clk)
begin -- process
if rst = '1' then
foo <= (others => '0');
end if;
if clk'event and clk = '1' then -- rising clock edge
-- Some code...
else
somethingelse <= '0';
end if;
end process;
This kind of unholy synchronous/asynchronous process will usually be
accepted by the synthesis tool and work badly, if at all whereas it
is not possible to create any asynchronous behaviour if the first version
is used. (Or rather, synthesis tools will not allow it)
So I'd summarize the advantages/disadvantages like this:
wait until rising_edge(clk):
+ No sensitivity list to worry about
+ No asynchronous behaviour to worry about
- Might lead students to use wait in ways they shouldn't
if rising_edge(clk) then:
+ No wait statement
+ A bit more general
- Fully legal to create asynchronous logic, including latches
- Sensitivity list to worry about
/Andreas
Article: 118759On 3 Mai, 13:43, NA <madid87-MAK...@yahoo.com> wrote: > Hello. > I'm new to FPGA desing, so could you please help me with this little > problem. > To run my sensor I must have some delays in communication with it > (DS18B20). > > When I put this into my code > "wait for 500 us;" > > I get --> parse error, unexpected WAIT > > I tried to desing a down counter with set and reset, and used wait until > "count=0" but I get the same error. > > Here is a simple example. > > **************** > architecture Behavioral of ispis is > begin > > DQ <= '0'; > wait for 500 us; > > End Behavioral; > **************** > > How to program delays for my code if "wait" wont work? Maybe I'm using it > in the wrong way? Thanks. wait can only be used in testbenches. not when targetting FPGA design. FPGA has no idea what 500 us is, you need to understand this first, then only you can have success with synthesis AnttiArticle: 118760
On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Lukats@xilant.com> wrot=
e:
> wait can only be used in testbenches.
> not when targetting FPGA design.
> FPGA has no idea what 500 us is, you need to understand this first,
> then only you can have success with synthesis
> Antti
Thank you very much.
Let's say I try to do something like this
**************************************
signal CTR : STD_LOGIC_VECTOR (15 downto 0) :=3D "000000000...";
process(CLKIN)
begin
if CLKIN'event and CLKIN=3D'1' then
CTR <=3D CTR - "0000000000000001";
end if;
end process;
DQ <=3D '0';
CTR <=3D "0110010000101"; -- some delay value at 50MHz clock speed
wait until CTR =3D '0';
**************************************
Again, parse error, unexpected WAIT
If some could just show me the simplest way do do a little delay in =
communication when I need one I would be able do to my project. It's a =
study project, my mentor has no time to help me :-(
Article: 118761On 3 Mai, 14:16, NA <madid87-MAK...@yahoo.com> wrote: > On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Luk...@xilant.com> wrote: > > wait can only be used in testbenches. > > not when targetting FPGA design. > > FPGA has no idea what 500 us is, you need to understand this first, > > then only you can have success with synthesis > > Antti > > Thank you very much. > Let's say I try to do something like this > > ************************************** > signal CTR : STD_LOGIC_VECTOR (15 downto 0) := "000000000..."; > > process(CLKIN) > begin > if CLKIN'event and CLKIN='1' then > CTR <= CTR - "0000000000000001"; > end if; > end process; > > DQ <= '0'; > CTR <= "0110010000101"; -- some delay value at 50MHz clock speed > wait until CTR = '0'; > ************************************** > > Again, parse error, unexpected WAIT > > If some could just show me the simplest way do do a little delay in > communication when I need one I would be able do to my project. It's a > study project, my mentor has no time to help me :-( YOU CAN NOT USE "wait" statement for FPGA design. YOU CAN NOT USE "wait" statement for FPGA design. YOU CAN NOT USE "wait" statement for FPGA design. YOU CAN NOT USE "wait" statement for FPGA design. YOU CAN NOT USE "wait" statement for FPGA design. read the above 5 times, and try again. AnttiArticle: 118762
On Thu, 03 May 2007 14:22:04 +0200, Antti <Antti.Lukats@xilant.com> wrote: > YOU CAN NOT USE "wait" statement for FPGA design. > read the above 5 times, and try again. > Antti So you can copy-paste that 5 times but you can't give a helpful suggestion. Thanks anyway.Article: 118763
On 2007-05-03, Ben Jones <ben.jones@xilinx.com> wrote:
> Those are by no means the only options. For example:
>
> process (clock)
> begin
> if rising_edge(clock) then
>
> -- Put your RTL code in here
>
> if reset = '1' then
>
> -- Put the code that resets any signals that need resetting in here
>
> end if;
>
> end if;
> end process;
>
> Pros/cons:
> - ???
- First time students will disobey the template and create
unholy processes which works in modelsim (most of the time)
but has no hope of ever working in a CPLD or FPGA :/
If the wait until rising_edge(clock) is used instead, the
tool will not accept anything which isn't synchronous no
matter how much you try.
Sure, we could (and of course _do_) say "Don't do that!", but
even so I don't think it is an exaggaration to say that at
least one group disobeys the template on every lab, leading to
much frustration (for them :)). In their defense, they usually
come from a programming background and they also have
faith that a design that works in ModelSim will work in
hardware. If they were experts in digital design they wouldn't
have to take this course after all :)
Anyway, this is a relatively minor point, what would be much
better in a teaching situation is if XST could be configured
to be more strict in what it accepts.
For example, I would like to be able to say that
latches should not be allowed to be inferred at all in a design
(unless they are instantiated manually). Please, implement
always_ff/_latch/_comb from SystemVerilog ASAP :)
(IIRC there is equivalent functionality in VHDL 2006 but I don't
remember the details right now.)
Something which also would be nice is the ability to flag
suspicious combinations of asynchronous/synchronous processes
as errors. While it might be ok with an asynchronous reset it is
probably not ok if that asynchronous reset is generated combinatorially
in the same process as in:
if bar="1001" then
foo <= (others => '0');
else if rising_edge(clk) then
foo <= foo + x;
...
/Andreas
Article: 118764On 3 Mai, 14:22, Antti <Antti.Luk...@xilant.com> wrote: > > ************************************** > > signal CTR : STD_LOGIC_VECTOR (15 downto 0) := "000000000..."; > > > process(CLKIN) > > begin > > if CLKIN'event and CLKIN='1' then > > CTR <= CTR - "0000000000000001"; > > end if; > > end process; > > > DQ <= '0'; > > CTR <= "0110010000101"; -- some delay value at 50MHz clock speed > > wait until CTR = '0'; > > ************************************** > > > Again, parse error, unexpected WAIT > > > If some could just show me the simplest way do do a little delay in > > communication when I need one I would be able do to my project. It's a > > study project, my mentor has no time to help me :-( > > YOU CAN NOT USE "wait" statement for FPGA design. Indeed, you can't. But I consider this to be a deficiency of the tools. The above example is easy to synthesize. There have been academic proofs of concept decades ago. Essentially you only need to add a state per wait statement. Kolja SulimmaArticle: 118765
On May 3, 7:22 am, Antti <Antti.Luk...@xilant.com> wrote: > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > > read the above 5 times, and try again. > > Antti WRONG! You cannot wait for TIME in synthesizable code. You can wait until rising_edge(clk)! Not usually the best coding style, but it can be done and is accepted by most synthesis tools. NA, You can wait for time in a testbench (simulation code written to test the synthesizable FPGA design code). An additional problem is that the wait statement is a sequential statement (inside a process), but it is being used in a concurrent context (outside a process). That won't work for simulation or synthesis. Concurrent assignment statements are each their own little implied process, running in parallel with other concurrent assignment statements and processes. The order in which they appear in the code is not necessarily the order in which they execute, and they may execute repeatedly/continuously. AndyArticle: 118766
On 3 Mai, 14:58, Andy <jonesa...@comcast.net> wrote: > On May 3, 7:22 am, Antti <Antti.Luk...@xilant.com> wrote: > > > YOU CAN NOT USE "wait" statement for FPGA design. > > YOU CAN NOT USE "wait" statement for FPGA design. > > YOU CAN NOT USE "wait" statement for FPGA design. > > YOU CAN NOT USE "wait" statement for FPGA design. > > YOU CAN NOT USE "wait" statement for FPGA design. > > > read the above 5 times, and try again. > > > Antti > > WRONG! > > You cannot wait for TIME in synthesizable code. You can wait until > rising_edge(clk)! Not usually the best coding style, but it can be > done and is accepted by most synthesis tools. > > NA, > > You can wait for time in a testbench (simulation code written to test > the synthesizable FPGA design code). > > An additional problem is that the wait statement is a sequential > statement (inside a process), but it is being used in a concurrent > context (outside a process). That won't work for simulation or > synthesis. > > Concurrent assignment statements are each their own little implied > process, running in parallel with other concurrent assignment > statements and processes. The order in which they appear in the code > is not necessarily the order in which they execute, and they may > execute repeatedly/continuously. > > Andy ah, ok yes. its really common that attempts are made to wait for time. and yes, as best coding the wait should not be used at all.. so for a total newbie its really good advice not to consider using wait statemant in synthesisable code at all. AnttiArticle: 118767
Hey wait a minute, You can use wait statements in FPGA design but not as the OP thinks like "wait clk'event and clk='1'" But using wait is not something I recommend. The biggest problem here is that the OP needs to understand the difference of parallel statements and sequential statements. Outside processes, statements are parallel and inside processes statements are sequential Your statements outside the process are parallel but your attempt looks like you think them as sequential. Göran Bilski "Antti" <Antti.Lukats@xilant.com> wrote in message news:1178194924.809806.120610@p77g2000hsh.googlegroups.com... > On 3 Mai, 14:16, NA <madid87-MAK...@yahoo.com> wrote: >> On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Luk...@xilant.com> >> wrote: >> > wait can only be used in testbenches. >> > not when targetting FPGA design. >> > FPGA has no idea what 500 us is, you need to understand this first, >> > then only you can have success with synthesis >> > Antti >> >> Thank you very much. >> Let's say I try to do something like this >> >> ************************************** >> signal CTR : STD_LOGIC_VECTOR (15 downto 0) := "000000000..."; >> >> process(CLKIN) >> begin >> if CLKIN'event and CLKIN='1' then >> CTR <= CTR - "0000000000000001"; >> end if; >> end process; >> >> DQ <= '0'; >> CTR <= "0110010000101"; -- some delay value at 50MHz clock speed >> wait until CTR = '0'; >> ************************************** >> >> Again, parse error, unexpected WAIT >> >> If some could just show me the simplest way do do a little delay in >> communication when I need one I would be able do to my project. It's a >> study project, my mentor has no time to help me :-( > > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > YOU CAN NOT USE "wait" statement for FPGA design. > > read the above 5 times, and try again. > > Antti > > > > > > > > > > > > > > > > > >Article: 118768
On 3 Mai, 14:45, NA <madid87-MAK...@yahoo.com> wrote: > On Thu, 03 May 2007 14:22:04 +0200, Antti <Antti.Luk...@xilant.com> wrote: > > YOU CAN NOT USE "wait" statement for FPGA design. > > read the above 5 times, and try again. > > Antti > > So you can copy-paste that 5 times but you can't give a helpful suggestion. > Thanks anyway. maybe some day later you understand that I did give good advice. something need to learned. FPGA (or any hardware) DOES NOT WAIT... so its better not to get used to "wait", when any signal changes then it propagates with interconnect+logic delay time, all FPGA vendors try to make those delays as small as possible. so try to understand that FPGA is not actually waiting for something to happen, but contrary and event (change of signal values) is immediatly processed at maximum speed Any amount of events happening at same time all are handler in parallel. so for your delay, you need to use some flag that gets set if some number of clock cycles is elapsed eg you are not wait until that happens, but you should describe what should be done if the condition (time elapsed) exists. if my first answer did not please you, well maybe it helps to understand the basic better at the end. its really the basic thing that you have not understand yet. you should never forget that any electronic circuit can be built from single primitive NAND2 - in FPGA there are more primitives so you do not need need to build flip-flops from NAND2 gates, but same rules apply. if you write a clocked process this (if it is synthesiseable) CAN always be mapped to sea of gates of NAND2 (and logic gate does not know how to wait, if it is ideal it has 0 delay, if not then it has small delay). ;) AnttiArticle: 118769
NA wrote: > ************************************** > signal CTR : STD_LOGIC_VECTOR (15 downto 0) := "000000000..."; > > process(CLKIN) > begin > if CLKIN'event and CLKIN='1' then > CTR <= CTR - "0000000000000001"; > end if; > end process; > > DQ <= '0'; > CTR <= "0110010000101"; -- some delay value at 50MHz clock speed > wait until CTR = '0'; > ************************************** > > Again, parse error, unexpected WAIT The reason for the parse error is that WAIT is not allowed at the position you have used it, see the BNF of VHDL: http://tech-www.informatik.uni-hamburg.de/vhdl/tools/grammar/vhdl93-bnf.html wait_statement is a sequential_statement, which is allowed in subprograms, processes or as part of sequence_of_statements, which is allowed in loops and conditions. But that's only the formal reason. Most synthesizes tools won't allow you to use it in processes, too, because VHDL is intended as a hardware description language. Sequential logic has to be implemented with state machines, see for example my DS2432 ROM id reader, which uses the same 1-wire protocol as the DS18B20: http://www.frank-buss.de/vhdl/spartan3e.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 118770
"LilacSkin" <lpaulo07@iseb.fr> wrote in message
news:1178190162.347539.50510@u30g2000hsc.googlegroups.com...
>
> Sorry I don't have time to drive directly the PLB signals.
> I just want to build a burst transaction.
What I'm saying is, you might find it quicker and easier to drive the PLB
signals directly. It's not very complicated. There are just a handful of
signals that are involved in a burst transaction, plus a few more "static"
ones that tell the data width and transaction type.
Sad to say, but the PLB protocol is (in my experience) better documented
than the IPIF, mostly because the CoreConnect standard is widely used
whereas the IPIF wrapper layer is Xilinx proprietary.
> You say that "The slave is responsible for calculating all subsequent
> addresses after that."
> I agree with you, but I need to present a data to the slave component.
> So I had to count my ip2ip adress in order to present the data from my
> slaves registers of my slave/master component to the slave component.
That depends entirely on what you're doing. If you have a random-access
buffer in your component and you want to read out its contents in linear
order and write them to the slave device, then yes, you would have to count
the burst cycles yourself. But if your data are coming from a FIFO (which
counts internally for itself), then in that case you would not need your own
counter.
I'm afraid I don't think I'm getting very close to answering your original
question, though, for which I apologize... questions...
(1) Are you debugging this in hardware or in simulation?
(2) What is the slave device you are accessing?
-Ben-
Article: 118771On May 3, 1:16 pm, NA <madid87-MAK...@yahoo.com> wrote: > On Thu, 03 May 2007 13:59:30 +0200, Antti <Antti.Luk...@xilant.com> wrote: > > wait can only be used in testbenches. > > not when targetting FPGA design. > > FPGA has no idea what 500 us is, you need to understand this first, > > then only you can have success with synthesis > > Antti > > Thank you very much. > Let's say I try to do something like this > > ************************************** > signal CTR : STD_LOGIC_VECTOR (15 downto 0) := "000000000..."; > > process(CLKIN) > begin > if CLKIN'event and CLKIN='1' then > CTR <= CTR - "0000000000000001"; > end if; > end process; > > DQ <= '0'; > CTR <= "0110010000101"; -- some delay value at 50MHz clock speed > wait until CTR = '0'; > ************************************** > > Again, parse error, unexpected WAIT > > If some could just show me the simplest way do do a little delay in > communication when I need one I would be able do to my project. It's a > study project, my mentor has no time to help me :-( You do not want the chip to sit and wait at the point you have implemented the 'wait'. For this reason, wait is only used during a testing activity and is not allowed during synthesis. What you want to do is to initialise a timer with a value that is proportional to the required delay and to decrement this timer on each clock transition until the value becomes zero (as you have basically done in the above code). The problem is that you have placed the 'wait' statement there which is not allowed when synthesising. Depending upon the complexity of your FPGA application - I would use a 'state machine' approach to coding the VHDL. Daver2Article: 118772
On May 2, 9:11 am, jhal...@TheWorld.com (Joseph H Allen) wrote:
> In article <1178033628.894456.55...@p77g2000hsh.googlegroups.com>,
> Quang Anh <nvq...@gmail.com> wrote:
>
> >> // Concise priority arbiter
> >> input [26:0] req; // Bit zero is highest priority
> >> wire [26:0] gnt = req & -req; // Isolate least significant set bit
> >I'm so sorry that I can NOT understand your idea. Maybe, I should read
> >the documents you recommend first. Anyway, it would be great for me if
> >you spend your ttime explaining to me again.
>
> Try an example: suppose (for 10 bits) req is 1101011000
>
> The definition of '-' (2's complement negate) is to invert each bit and then
> add 1, so lets see what happens:
>
> Invert: 0010100111
> Now if you AND this with req you'll get zero. But look at what happens when
> you add 1: the carry propogates through all of the trailing ones until the
> first zero is hit:
>
> Negate: 0010100111 + 1 --> 0010101000
> Now if you AND this with req you'll get: 0000001000
>
> Bit 3 is the highest priority requester.
>
> --
> /* jhal...@world.std.com AB1GO */ /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Since gnt1 implies that there was a req1, wouldn't it be better
(faster) to use req1 in the winner selection?
wire [26:0] winner = |req1 ? gnt1 : gnt; // Start from bit zero if
none
Article: 118773On 2 Mai, 19:44, dalai lamah <antonio12...@hotmail.com> wrote: > Un bel giorno Antti digit=F2: > > > I really dont understand why Xilinx isnt hiring people who can develop > > and test software? > > Is the world-wide shortage of engineers really that bad? > > Actually some bugs and missing features - especially in the user interface > - are quite funny, for example the editor that hangs forever if you try to > use the dead keys (i.e.http://en.wikipedia.org/wiki/Dead_key). Or is it > just me? > > -- > emboliaschizoide.splinder.com My god, you are right! Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!! Well the workaround is simple, not to use dead keys. But its really hard to imagine how some company is able to develop software with such bugs! So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need kill and loose changes!), is minor, some other issues with EDK 9.1 are not: for 3 installation attempts: site 1) works after AR21143 site 2) starts up, but build process does not do anything. just hanges there... nothing happens. site 3) XPS does not start and complains entry point missing in libxercesc.dll the above issues are pretty much major (eg stop runngin XPS completly) so I have some more troubleshooting to get past next EDK 9.1 bugs.. AnttiArticle: 118774
Antti wrote: > If Xilinx really does ANY software testing before release things like > that should no happen. > With ALL latest major releases the "time to first fatal error" from > the new install has been > less than 20 minutes. This is not acceptable for software that is to > be used to develop commercial products. I've worked with Altera Quartus and Xilinx ISE and both has bugs, in Quartus once they released a hotfix on top of a service pack to fix a major bug with state machines. This is far more critical than GUI problems with ISE/EDK (but I assume there are similar problems with synthesizing in ISE, too). Would be a good idea to combine both designing tools (but using the GUI of Quartus, because it's nicer than the ISE GUI) and open source it. In the end this would lead to less development cost for all: the FPGA companies, because they don't need to write both the same things and for users of the program, because they can help bugfixing it and using a more stable program. Company secrets could be moved to plugin modules. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
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