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 88275

Article: 88275
Subject: Re: Where can i find GeneticFPGA toolkit
From: Rob Ryland <RrEoMb@OrVoEbTrHyElCaAnPdS.com>
Date: Sun, 14 Aug 2005 05:33:24 GMT
Links: << >>  << T >>  << A >>
"Eric" <ericjohnholland@hotmail.com> wrote in
news:1123303914.495112.241380@g49g2000cwa.googlegroups.com: 

> Genetic Algorithm pseudo code:
> 
> Problem: Solve 2x+1 = 7 (we know the answer is 3, but work with me)
> 
> Step #1 Generate a Random population of numbers:
> 
> Population = 1, 6, 8, 4
> 
> Step #2 Chose a fitness function. Ours will be Error = ABS(1-(2x +
> 1)/7)
> 
>      Error(1) = ABS(1-(2x1+1/7)) = 0.57
>      Error(6) = ABS(1-(2x6+1/7)) = 0.86
> Error(8) = ABS(1-(2x8+1/7)) = 1.43
>      Error(4) = ABS(1-(2x4+1/7)) = 0.29
> 
>      The number with the smallest Error is closest to the answer.
>      (Still 
> with me?)
> 
> Step #3 Repopulate your population based on your fitness function
> results. This is the tough part to grasp.  We need to normalize all of
> the errors so we can get a repopulation percentage. This will help us
> get the new population of numbers.
> 
>      Take the total of the error 0.57 + 0.86 + 1.43 + 0.29 = 3.15
> 
> 3.15/0.57 = 5.53
>                3.15/0.86 = 3.66
>                3.15/1.43 = 2.20
>                3.15/0.29 = 10.86
**************    Bunch of quoted text trimmed   *********************
> 
> 
> Kind of make sense???
> 
> 
> Eric
> 

Good lord, that will just confuse them!... 
    	Of course you realize that your example algorithm converges a
    little slower than just guessing until you've guessed the right
    answer. I say a little slower because what you've described
    essentially IS just guessing until you happen upon the right answer,
    with a few extra operations to slow everything down! 	The magic in a
    genetic algorithm comes from the SEX, which happens in the crossover
    that you omitted in step 4 above. You HAVE to come up with a way to
    combine two 'pretty good' solutions to get another 'pretty good,
    maybe a bit better' solution. Without that combination step
    (analogous to sex in the world of biology), you don't have a genetic
    algorithm at all! 	Now finding a way to combine two 'pretty good'
    solutions to come up with a new 'pretty good' solution is sometimes
    difficult. In your example it would be easy; simply average (or
    perhaps a randomly weighted mean) the parents to get the offspring.
    Now that would actually converge to a solution in your example. 
    	The mutation part is less important than the sex part, but still
    needed. But i don't think i've EVER seen mutation implemented as
    simply making up a wholy new, randomly generated member of the
    population. That would be no better than (and roughly equivilent to)
    having a larger initial population. The mutation must be a
    relatively small change to an existing member of the population. The
    idea is that your population will, after a few generations, be much
    better adapted than a randomly generated individual and a small
    change will have a decent chance of being 'pretty good' too. 
    
    	I don't mean to be insulting or belittle the contribution to the
    newsgroup, but genetic algorithms are important and your example
    could easily confuse people. 

-Rob Ryland

Article: 88276
Subject: Glitches in Output of FSM
From: Sudhir.Singh@email.com
Date: 13 Aug 2005 23:10:47 -0700
Links: << >>  << T >>  << A >>
Hi All,
I have a state machine which produces control signals (synchronous
Reset and Enable) for a synchronous counter. The control signals are
generated based on the current state and a 8 bit data input.
I am seeing glichtes in both output control signals near the rising
clock edges. The 8 bit data input is registered.
Is there any way to get rid of the glicthes?

The VHDL code looks something like this

FSM: process(CurrentState,DataIn,Count,NewFrame,...)
begin
   CntrRst <= '0';       -- counter reset
   CntrEn <= '0';        -- counter enable

   case CurrentState is
      when State0 =>
         if NewFrame = '1' then
            NextState <= State1;
         else
            NextState <= State0;
            CntrRst <= '1';
         end if;

      when State1 =>
         case Count is
            when "00000" =>
               if DataIn = x"00" then
                  NextState <= State1;
                  CntrEn <= '1';
               else
                  NextState <= State0;
                  CntrRst <= '1';
               end if;
            when "00001" =>
            -- same as above except checking for a different
            -- DataIn
            -- All other cases test for different DataIn Values

            .
            .
            .
         end case;
   end case;
    
end process;


Thanks
Sudhir


Article: 88277
Subject: Avnet spartan3E development board
From: "CMOS" <manusha@millenniumit.com>
Date: 14 Aug 2005 00:37:53 -0700
Links: << >>  << T >>  << A >>
hi,
im hoping to buy the following FPGA development board from Avnet. If
anyone got any experiance with it please let me know.

Model: SP3E-EVL100
Link:
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html


thank you.
CMOS


Article: 88278
Subject: Modular design flow
From: "Fpga_Designer" <FPGA05@gmail.com>
Date: 14 Aug 2005 00:44:38 -0700
Links: << >>  << T >>  << A >>
Hello all,

I am currently using xilinx modular design flow to develop a simple
design. The top level design has an inout port for communicating data
between an external memory and fpga. I have implemented the necessary
control logic for this port in one of the modules and port mapped the
port of the module to the top level inout port. After having done this
when I run (ngdbuild -modular initial top.edd) with all the modules
instantiated (black boxes only) I receive the following error
"ERROR:NgdBuild:456 - logical net '***' has both active and tristate
drivers".

Can anyone suggest what needs to be done in this regard.

Thanks


Article: 88279
Subject: Re: creating HARD MACROs broken in ISE 7.1 SP3 ?
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 14 Aug 2005 10:48:15 +0200
Links: << >>  << T >>  << A >>
<bret.wade@gmail.com> schrieb im Newsbeitrag
news:1123944130.789425.98570@f14g2000cwb.googlegroups.com...
> Hi Antti,
>
> You would have had your solution a day earlier if you'd put a little
> more effort into the Answers search. Something like "7.1i add external
> pin" works for this case. You can't always depend on your posting being
> read by the person who wrote the Answer Record.
>
> There is another FPGA Editor issue that you may run into:
> http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667
>
> Regards,
> Bret
>

Hi Bret

yes you are absolutly right, I could have found the AR myself but I did not
instead of spending more time in search for AR (what I did not know to
exist)
I opened a WebCase and yielled loud at caf - thats not very good, and does
not always yield results.

I agree that all AR's can be found by entering some 'good' keywords into the
search, but its very often that you dont find the AR even if it exists.
Maybe
its only my dis-ability to find the Xilinx AR's, but it is really not the
first
time I have not found the specific AR until pointed out by AR number by
some Xilinx FAE.

Maybe all other people are more talented finding Xilinx AR's, can be.

---

I am not seeing problems as described in AR21667, but before the patch
for exptpin fix I did see another error during translate, maybe that is
fixed
with the exptin patch, I still need to check that.

Antti
PS yes I will try to search more hard on AR and errata stuff in the future,
maybe
one day I learn the trick to find proper ARs quickly without help from
others.







Article: 88280
Subject: Re: Avnet spartan3E development board
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 14 Aug 2005 10:51:19 +0200
Links: << >>  << T >>  << A >>
"CMOS" <manusha@millenniumit.com> schrieb im Newsbeitrag
news:1124005073.000044.130440@g47g2000cwa.googlegroups.com...
> hi,
> im hoping to buy the following FPGA development board from Avnet. If
> anyone got any experiance with it please let me know.
>
> Model: SP3E-EVL100
> Link:
>
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html
>
>
> thank you.
> CMOS
>

To my knowledge there are NO S3e based boards shipped to customers and also
virtually no S3e chips sent to 'normal' customers. So there could be no one
around with experience with S3e boards as of today.

I think the S3e eval boards should start shipping in September, so after
that you can expect some comments as well.

Antti



Article: 88281
Subject: Re: creating HARD MACROs broken in ISE 7.1 SP3 ?
From: "austin" <austin@xilinx.com>
Date: 14 Aug 2005 08:16:45 -0700
Links: << >>  << T >>  << A >>
Ed,

That is why I don't like to see these kinds of complaint sessions here
on comp.arch.fpga.

1)  Antti would have received his answer through the hotline, but as he
is an frieend of a friend, things were done to get a response back
faster than it would have otherwise.

This may have been a mistake.  With 250,000 active seats of software
out there making designs, we have to support all of them, and try to do
so with the same high level of quality.  As much as I feel for Antti's
situation, I can't respond to everyone.  Peter and I would make a
terrible hotline response team.

Instead, he and I act as "quality assurance" to make sure our responses
are meeting the mark, and succeeding.

2) It opens the door for everyone who ever had an issue to add their
two cents.

Of course we test the new software.  In fact, we are adding test cases,
and whole new test requirements with every service pack that goes out.
Are we absolutely perfect?  Not yet (one can hope).   Is our software
getting more, or less buggy?  I think in goes in cycles.  Virtex 4
added 100 (that we talk about) new features and capabilities.  All of
those had to get supported.  That is a significant development of new
software.  For every X lines of code written there is a bug.  For every
Z bugs fixed, there is a new bug created.

Best thing you can do for software is stop adding new features to it,
but unfortunately, we can't do that.  Moore's Law has three of four
more turns of the wheel left in it (in its present form - as far as we
can see), so we must continue to do what has made us so successful,
innovate.

(After 10 nm, no one really knows where we go, but we are certain that
programmable logic becomes more valuable, not less, regardless of the
technology.  Carbon nanotube, organic self assembly, etc. are merely
the means to implement the FPGA.)

I am not providing you with an excuse, just letting you know what the
reality is.  We test, and we test a lot.  But, with new products, and
new features, we can't be perfect, and we provide the fixes on a very
timely basis (usually every bug found is fixed in the next service
pack, or sooner by a tactical patch).

Austin


Article: 88282
Subject: Re: Delay implementation and logic optimization.
From: Alex <al.lopich@gmail.com>
Date: Sun, 14 Aug 2005 19:00:22 +0100
Links: << >>  << T >>  << A >>
Well it is fully asynchronous design - sort of concept-proof,
more in demonstration purposes. I know FPGA is not the proper platform
for it at all, however everything is working fine, apart that problem.

So can anyone help with the problem when the synthesiser optimize the
design by throwing buffer elements away?



-- 
Alex

Article: 88283
Subject: Clock for serializer with a Spartan3
From: dalai lamah <antonio12358@hotmail.com>
Date: Sun, 14 Aug 2005 18:18:36 GMT
Links: << >>  << T >>  << A >>
Which is the preferred way to generate the output clock for a deserializer
made with a shift register? For example, let's say I feed a 4-bit shift
register with a 500 MHz signal, so that I have to store four bits at 125
MHz into a BRAM (or just latch them). How do I generate this 125 MHz clock?
I can't use a DCM because the input frequency is out of range, but if I
generate the clock with common logic (e.g. a binary counter or a shift
register), how can I be sure that it won't violate the hold/setup times in
respect to the four output bits?

Thank you!

-- 
asd

Article: 88284
Subject: Re: EDK IPIF + User Core
From: Paul Hartke <phartke@Stanford.EDU>
Date: Sun, 14 Aug 2005 11:21:12 -0700
Links: << >>  << T >>  << A >>
I'm not sure what you mean, the WFIFO/RFIFO datapaths are separate from
the IP2BUS_DATA and BUS2IP_DATA signals.  The IPIF generated by the IP
Import Wizard automatically connects things up internally to get data
to/from RFIFO/WFIFO to the bus.  

Are you planning on using the vacancy/occupancy counters for the FIFOs? 
I see them working in simulation but running on the hardware, reading
each from the processor always returns zero.  Empty/Full and the FIFO
operations themselves are working in both hardware and software.  

Paul

el_boricua wrote:
> 
> I am simulating a IPIF + user core using the BFM simulation model and
> in my test   I can succesfully write to the WFIFO (write fifo) and
> write to the RFIFO (read fifo) but for some reason the data from the
> read fifo doesn't get dumped to the IP2BUS_DATA (Data Bus) is there any
> signal that I should assert from the IPIF interface to dumped the data
> from the RFIFO to the bus?
> 
> Thanks,
> Noel

Article: 88285
Subject: Re: Glitches in Output of FSM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 14 Aug 2005 11:23:05 -0700
Links: << >>  << T >>  << A >>
Sudhir,
so you have two sets of synchronous signals (hopefully synchronized by
the same global clock) and you combine them through combinatorial logic
to generate 2 control signals for the counters.
Obviously, you will generate glitches on these outputs, as a result of
prop delay differences in the combinatorial logic.  But these glitches
occur a few nanoseconds AFTER the active clock edge, and they are,
therefore, irrelevant and cause no harm.
The beauty of synchronous logic is that inputs need only be stable
during the set-up time BEFORE the clock edge.
Peter Alfke, Xilinx Applications (from home)


Article: 88286
Subject: Re: Clock for serializer with a Spartan3
From: "Marc Randolph" <mrand@my-deja.com>
Date: 14 Aug 2005 12:03:20 -0700
Links: << >>  << T >>  << A >>

dalai lamah wrote:
> Which is the preferred way to generate the output clock for a deserializer
> made with a shift register? For example, let's say I feed a 4-bit shift
> register with a 500 MHz signal, so that I have to store four bits at 125
> MHz into a BRAM (or just latch them). How do I generate this 125 MHz clock?
> I can't use a DCM because the input frequency is out of range, but if I
> generate the clock with common logic (e.g. a binary counter or a shift
> register), how can I be sure that it won't violate the hold/setup times in
> respect to the four output bits?

Howdy,

Two ways to solve this:

1. If the 125 MHz "clock" isn't needed for a considerable amount of
logic, strongly consider generating and using a clock enable that is
actually in the 500 MHz domain.

2. If you have a bunch of logic that needs to run at 125 MHz, the DCM
has a CLKIN_DIVIDE_BY_2 mode to handle higher frequencies:

http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/cgd/cgd0064_25.html

Have fun,

   Marc


Article: 88287
Subject: XST (ISE 6.1i): Error: It's interesting and surprising
From: "QRaheeL" <qraheel@gmail.com>
Date: 14 Aug 2005 12:27:24 -0700
Links: << >>  << T >>  << A >>
Hi guys.

An intesresting problem occured when I used "more than three" signals
in always block sens list.

XST (ISE 6.1i) reported the following error:

ERROR:Xst:1468 - dummy.v line 25: Unexpected event in always block
sensitivity list.

Same code is successfully compiled & simulated in MOdelSim5.7SE.

What kind of problem is this ?
Related to parser/editor/etc ??

//-------- C O D E - C O D E --------///

module dummy(x);
    output x;
	 assign x = 1'b0;

	 reg a,b,c,d;
	 reg z;

	 initial
	 begin
	 	a=0;	b=0;	c=0;	d=0;	z=0;
		#100 $stop;
	 end

	 always  	#10 a=~a;
	 always  	#15 b=~b;
	 always  	#20 c=~c;
	 always  	#5  d=~d;

	always @(posedge a or posedge b or posedge c or posedge d )	begin
		if(a)	z=~z;
		else if(b)z=~z;
		else if(c)	z=~z;
		else if(d)	z=~z;
	end
endmodule


Article: 88288
Subject: Delay implementation and logic optimization.
From: Alex <al.lopich@gmail.com>
Date: Sun, 14 Aug 2005 21:18:11 +0100
Links: << >>  << T >>  << A >>
Hi guys.

	Implementing asynchronous delays in my design via a chain of buffer  
elements
	(I know it's a bad practise, but I need few ns delays) I faced the  
problem with
	removing them from the design, as Xilinx synthesiser removes these  
elements from
	the design, although the OPTIMIZE option is off.

	So I'd like to ask if anyone can tell me where I missed something, and  
also if someone
	already implemented small delays via internal FPGA units (not RC  
chains)which elements
	may provide the biggest delay (in order to save space).

	Thanks a lot.

-- 
Alex

Article: 88289
Subject: Re: globally asyncronous vs locally syncronous?
From: Alex <al.lopich@gmail.com>
Date: Sun, 14 Aug 2005 21:18:24 +0100
Links: << >>  << T >>  << A >>
Hi,

Maybe I haven't got your problem, why can't you use asynchronous memory,
so you  could vary the processor clock as you like. Synchronous design will
definitely work, however you will loose in performance. As a compromise  
you can always
gate clock, which is probably not the best practise in FPGA design.
At any rate - more details on your system arch. would help.
Regards,
Alex

-- 
Alex

Article: 88290
Subject: Re: XST (ISE 6.1i): Error: It's interesting and surprising
From: "johnp" <johnp3+nospam@probo.com>
Date: 14 Aug 2005 13:31:07 -0700
Links: << >>  << T >>  << A >>
Your results are not surprising.  Although your code is legal Verilog
and is
able to simulate, it's not synthesizable.  What type of flip-flop would
you expect
XST to infer from the
    "always @(posedge a or posedge b or posedge c or posedge d ) "
construct?

You need to re-think your code!

Good luck!

John Providenza


Article: 88291
Subject: Re: Glitches in Output of FSM
From: Sudhir.Singh@email.com
Date: 14 Aug 2005 13:47:45 -0700
Links: << >>  << T >>  << A >>
Peter, thanks for your reply.
Sudhir


Peter Alfke wrote:
> Sudhir,
> so you have two sets of synchronous signals (hopefully synchronized by
> the same global clock) and you combine them through combinatorial logic
> to generate 2 control signals for the counters.
> Obviously, you will generate glitches on these outputs, as a result of
> prop delay differences in the combinatorial logic.  But these glitches
> occur a few nanoseconds AFTER the active clock edge, and they are,
> therefore, irrelevant and cause no harm.
> The beauty of synchronous logic is that inputs need only be stable
> during the set-up time BEFORE the clock edge.
> Peter Alfke, Xilinx Applications (from home)


Article: 88292
Subject: Re: Where can i find GeneticFPGA toolkit
From: apsolar@rediffmail.com
Date: 14 Aug 2005 17:42:32 -0700
Links: << >>  << T >>  << A >>
Hi Rob
I undertsand why you are making a point about crossover.I have done
exactly the same thing. I use a special class to compare and sort the
population based on their fitness. Keeping in mind 'elitism',I also
copy the best solution to the new population. Then from a population of
six, I select 4 best values and average out consequent numbers.
Mutation- to randomise mutation process ,I select 4 members after
crossover and either add 1 0r subtract 1 depending on computer clock
ticks.This process is completely random.
Here's a piece of code for the above:

//Elitism - copy the best solution to the next generation
Array.Sort(RepopulationPercentage);
Best = RepopulationPercentage[popsize-1].accessElement;
       listBox1.Items.Add("Best = "+Best);

//Crossover
	int m=popsize-1;
	listBox1.Items.Add("After Crossover");
	listBox1.Items.Add(population[0]);
	for(i=1;i<popsize-1;i++) //elements
	{
	population.SetValue((int)((RepopulationPercentage[m].accessElement+RepopulationPercentage[m-1].accessElement)/2),i);
	listBox1.Items.Add(population[i]);
		m--;
	}
	if(dt.Ticks%2 == 0)
	population[popsize-1]=Best - 1;
	else
	population[popsize-1]=Best + 1;

//Mutation
	listBox1.Items.Add("After Mutation");
	listBox1.Items.Add(population[0]);
	for(i=1;i<popsize;i=i+2) //elements
	{
		if(dt.Ticks%2 == 0)
          	population.SetValue((int)(population[i]+1),i);
		else
		population.SetValue((int)(population[i]-1),i);
		listBox1.Items.Add(population[i]);
	}

Eric's psuedo code and a genetic algorithm template from a website
helped me write the code.
Ankit


Article: 88293
Subject: Re: Delays in verilog
From: Tullio Grassi <tgrassi@mail.cern.ch>
Date: Mon, 15 Aug 2005 03:21:49 +0200
Links: << >>  << T >>  << A >>

my understanding of verilog is that the code below is umbigous,
so it is a bad practice anyway, with or without delays.
The reason of the ambiguity is that assignements are
analyzed in parallel, so if condition 2 is true, you
don't know if the synthezaizer implemented 
  out_reg <= 2'd0; 
or
  out_reg <= 2'd2;



On Fri, 12 Aug 2005, Jonathan Bromley wrote:

> Consider the following rather useful synthesis idiom:
> 
> always @(posedge clk) begin
>   out_reg <= 2'd0;  // Default value
>   if (condition_1)
>     out_reg <= 2'd1;
>   if (condition_2)
>     out_reg <= 2'd2;
> end
> 
> Especially if there are complicated nested conditions,
> this can be a very neat way of describing default 
> conditions - there's no need to check that you have
> written the right "else" clauses to mop up all the 
> default possibilities.  However, let's now suppose 
> that you added delays to the assignments - but you 
> missed one:
> 
>   out_reg <= #1 2'd0;
>   if (condition_1)
>     out_reg <= #1 2'd1;
>   if (condition_2)
>     out_reg <= 2'd2;  // oops, forgot the delay
> 
> Now imagine that we execute the code, and condition_1
> is false but condition_2 is true.  The first assignment
> schedules an update on out_reg one time unit into the future.
> The second assignment is not executed at all, because
> its "if" conditional is false.  The third assignment 
> schedules an update in the immediate future.  
> 
> "<= #T" delay in Verilog is a transport delay, so both 
> updates remain active.  So the assignment that we 
> wanted to happen,
> 
>   out_reg <= 2'd2 ,
> 
> will take place immediately but, one time unit later, it
> will be superseded by the default assignment.  The design
> is broken in a way that's very hard to diagnose, and 
> what's worse, simulation and synthesis will disagree
> (synthesis will give the answer that you wanted, because
> it ignores the delays).  
> 
> The only way to get this right is to ensure that all 
> assignments have exactly the same delay.  This is
> completely absurd, and impossible to maintain across
> a large always block - especially if it calls tasks.
> DON'T DO IT.  No delays, please.
> 
> If you really want to delay the output, then make your 
> clocked assignments to an internal variable, and copy
> that on to the output port using a continuous assign
> with a delay.  In that way the delay is centralised in
> one place and is not subject to the kind of error I
> described.
> 
> Note that VHDL does not suffer this problem, because 
> assignment delays are (by default) inertial and so 
> the intuitive "most recent assignment wins" rule 
> works as you'd expect, even if the delays are different.
> 

-- 
Tullio Grassi

======================================

Univ. of Maryland-Dept. of Physics   |
College Park, MD 20742 - US          |
Tel +1 301 405 5970                  |
Fax +1 301 699 9195                  |
======================================

Article: 88294
Subject: VHDL Array indexing Issue in Modelsim
From: pinod01@sympatico.ca
Date: 14 Aug 2005 18:45:13 -0700
Links: << >>  << T >>  << A >>
To all,

    I'm trying to create a test bench where an array data type of
"std_logic_vector" is read within a for loop and then stored to a file.
 The problem I'm facing is that the array accesses the starting index
of 0 twice and doesn't capture the last element of the array as it
should.  That is the line stated below as:  "refmemdata <= mem_arr(k)"
returns the value of the signal at k = 0 twice eventhough the value of
k in the second iteration of the loop is k = 1.  Why?   Any help would
be grateful.


Section of VHDL code for above problem:
======================================

-- Signal Declaration
signal refmemdata :std_logic_vector(2 downto 0);
type mem_vec_arr is array (0 to 4) of std_logic_vector(2 downto 0);
constant mem_arr: mem_vec_arr :=(0 => "000",1 => "001",2 => "010", 3 =>
"011", 4 => "100");

file data_vector_file: text open write_mode is
"D:\written_data_file.txt";

-- Array accessing and file storage
stimulus: process()
variable data_file_line: line;
begin
     for k in 0 to 4 loop
        wait until (clk'event) and (clk = '1');
        refmemdata <= mem_arr(k);
        write(data_file_line, to_bitvector(refmemdata));
        writeline(data_vector_file,data_file_line);

     end loop;

end process;


Article: 88295
Subject: ISE 7.1 'improvements' plus meandering....
From: "GPE" <See_my_website_for_email@cox.net>
Date: Sun, 14 Aug 2005 21:02:38 -0500
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:1124032605.076143.24740@g14g2000cwa.googlegroups.com...
> Ed,
>
> I am not providing you with an excuse, just letting you know what the
> reality is.  We test, and we test a lot.  But, with new products, and
> new features, we can't be perfect, and we provide the fixes on a very
> timely basis (usually every bug found is fixed in the next service
> pack, or sooner by a tactical patch).
>
> Austin
>

The things that bug me are the simple things that work with one version and 
with the next update they have been "improved" and no longer work.

For example (going from memory here...) - after upgrading to ver 7 when you 
get a compile error - you used to click on the error code and it would give 
you an explanation of the error.  Now when you click on the error code - it 
goes off and does a Xilinx websearch for the error - and the search includes 
my application specific variable names.  Naturally, everytime it comes back 
with 'error not found'.  Now how in the heck did a function such as that 
break?

Another example - I have an older design written in Abel (OK - it was 
written long, long ago).  Recently I modified the code to change the 
revision number within the CPLD.  Compiled it with version 7.1... it gives 
no errors and appears to compile just fine.  Download it to the part and 
nada.... nothing works.  I look at the JEDEC file and it's half blank. 
Strange as the compiler didn't give any errors.  Compiled the old, 
unmodified code with 7.1 - same results.  Compiled both old and new with 
version 6.1 and it all works just fine.

But, hey, to tell the truth - there really isn't a whole lot to complain 
about regarding Xilinx sotware now that I've tried Atmel's Prochip Designer. 
Phew!  Brings back memories of  the old XACT days with DOS!!!

Suggestion....
I use lots of Xilinx Vertex and XC9500xl parts.  Hey, these are good parts. 
But due to selection, for one of my projects, I often have to go with Atmel. 
They have the ATF150x series CPLD's which are DIRT cheap, operate from 5 
volts and come in a PLCC package.  Closest thing would be the Xilinx XC9500 
series but they cost far, far more.  I can easily fit the design in an 
ATF1504 which costs about $5.  To get the same design to compile within a 
Xilinx part - I had to keep bumping it up in density until I got to the 
XC95288... and these cost many times the $5 price.  It would be real nice if 
Xilinx would also supply CPLD's with this increased density, operate from 5 
volts,  be much cheaper like the Atmel parts and be in a large PLCC (MUST be 
socketable) package.  Heck, I can forgo the 5V with an LDO but still MUST 
retain 5V I/O interface like the XC9500XL's.

You know what would be real neat -- if somebody were to come up with a 
generic 5 volt, 40-PIN DIP CPLD in a high enough density to emulate a 6502 
or 6800 processor or the myriad of support parts that are no longer 
available.   Ohhhh.... I'd give an arm and a leg for a cheap and reliable 
source of this type of part!

-- Ed



Article: 88296
Subject: Re: Avnet spartan3E development board
From: "Alf Katz" <alfkatz@iremove.the.bloody.obvious.ieee.org>
Date: Sun, 14 Aug 2005 19:15:28 -0700
Links: << >>  << T >>  << A >>

"CMOS" <manusha@millenniumit.com> wrote in message 
news:1124005073.000044.130440@g47g2000cwa.googlegroups.com...
> hi,
> im hoping to buy the following FPGA development board from Avnet. If
> anyone got any experiance with it please let me know.
>
> Model: SP3E-EVL100
> Link:
> http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D21564%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html
>
>
> thank you.
> CMOS
>
Had a chance to play with one of these at one of Memec's (recently acquired 
by Avnet) X-Fest seminars.  They integrate with the tools well, and are 
fairly no-fuss.  Last I heard, they were due to be available for purchase 
about mid September.

Cheers,
Alf. 



Article: 88297
Subject: Spartan-3 configuration -- peculiar problem
From: ScreamingFPGA@yahoo.com
Date: 14 Aug 2005 19:21:08 -0700
Links: << >>  << T >>  << A >>
Hello All,
  I'm three days into this configuration problem,
so I think it's time to consult the experts.
Problem's like this usually seem trivial in
retrospect, but I've usually been looking in
the wrong places...

  Briefly, INIT line goes low one CCLK pulse after
DONE line goes high. Configuration loads and runs,
but INIT line low indicates a CRC error. The signals
look quite reasonable on a scope.

 Specifics:
 On a new prototype board I'm trying to congigure
a Spartan-3 3s1000-5fg456 using a 3.3V IO micro-
controller driving the fpga's config lines. Dedicated
config lines have serial resistor (100 ohm), as
per recommendation for 3.3V tolerant config.

  I'm using slave-serial mode to write config file,
which is stored on the micro's flash memory. I've
used the same micro and method successfully in other
products (but using Spartan-2).

  I send all data frames ( FFFFFFFF , AA995566 ,
... 20000000 ) start to end of file.

  I'm not sure exactly _where_ the DONE line should
go high. It would seem that it should go high at some
point after the last 32-bit configuration frame, but
in fact DONE transitions on the 7th CCLK pulse of the
(N-4)th configuration frame. XAPP452 shows this as being
[CMD Write Packet Data(DESYNC)] frame. The INIT line
goes low on the 8th CCLK pulse, Fpga operation commences
on the 9th CCLK pulse.

  All design tweaks (resistor value changes) and clock/
data timing tweaks result in the same behavior. I would
have thought that the CRC error would have prevented
startup of the fpga (CRC is _not_ disabled in bitgen), but
I guess this is not the case...

  If the DONE line _is_ going high early, I suppose this
would mean that extra CCLK transitions were seen by
the FPGA, pointing perhaps towards signal integrity
issues, but this would puzzle me, as under different
circumstances, the transitions happen at the same
points.

  The bit file is being generated by ISE6.2.02.

  Sorry, this post is longwinded, I'm hoping that someone
in the group has encountered a similar situation and can
perhaps point me in the right direction.

  Thanks in advance...

Scott@sdeviation.com


Article: 88298
Subject: Re: Avnet spartan3E development board
From: rickystickyrick@hotmail.com
Date: 14 Aug 2005 20:35:34 -0700
Links: << >>  << T >>  << A >>

Antti,

I consider myself a pretty regular customer and I have some 500e's.
Got them
a few weeks ago.

They'll be on a board and working this week.

Xilinx is a little late on the 3e's, but it isn't too bad.

Ricky.


Article: 88299
Subject: Re: ISE 7.1 'improvements' plus meandering....
From: Jim Granville <no.spam@designtools.co.nz>
Date: Mon, 15 Aug 2005 15:54:51 +1200
Links: << >>  << T >>  << A >>
GPE wrote:
> "austin" <austin@xilinx.com> wrote in message 
> news:1124032605.076143.24740@g14g2000cwa.googlegroups.com...
> 
>>Ed,
>>
>>I am not providing you with an excuse, just letting you know what the
>>reality is.  We test, and we test a lot.  But, with new products, and
>>new features, we can't be perfect, and we provide the fixes on a very
>>timely basis (usually every bug found is fixed in the next service
>>pack, or sooner by a tactical patch).
>>
>>Austin
<snip>
> 
> Another example - I have an older design written in Abel (OK - it was 
> written long, long ago).  Recently I modified the code to change the 
> revision number within the CPLD.  Compiled it with version 7.1... it gives 
> no errors and appears to compile just fine.  Download it to the part and 
> nada.... nothing works.  I look at the JEDEC file and it's half blank. 

Did you check the created files, to see if the fitter, or front end 
tools, dropped the ball ?

> Strange as the compiler didn't give any errors.  Compiled the old, 
> unmodified code with 7.1 - same results.  Compiled both old and new with 
> version 6.1 and it all works just fine.

ABEL is like assembler - there are still some designs where it is be
best tool. Did you send Xilinx this example, so they can fix it ?


> But, hey, to tell the truth - there really isn't a whole lot to complain 
> about regarding Xilinx sotware now that I've tried Atmel's Prochip Designer. 
> Phew!  Brings back memories of  the old XACT days with DOS!!!
> 
> Suggestion....
> I use lots of Xilinx Vertex and XC9500xl parts.  Hey, these are good parts. 
> But due to selection, for one of my projects, I often have to go with Atmel. 
> They have the ATF150x series CPLD's which are DIRT cheap, operate from 5 
> volts and come in a PLCC package.  Closest thing would be the Xilinx XC9500 
> series but they cost far, far more.  I can easily fit the design in an 
> ATF1504 which costs about $5.  To get the same design to compile within a 
> Xilinx part - I had to keep bumping it up in density until I got to the 
> XC95288... and these cost many times the $5 price.

With over 6x the MC's, the price delta is not suprising.
The ATF15xx series are usually ~2x, and in rare cases, up to 3x, more 
efficent so I'm surprised you need to go to 288MC in the 9500 to get a 
fit. Sounds more like a tool issue - did you show that to Xilinx ?


> It would be real nice if 
> Xilinx would also supply CPLD's with this increased density, operate from 5 
> volts,  be much cheaper like the Atmel parts and be in a large PLCC (MUST be 
> socketable) package.  Heck, I can forgo the 5V with an LDO but still MUST 
> retain 5V I/O interface like the XC9500XL's.

Lattice ispMACH4000 series show 5V I/O tolerance, but no PLCC.
PLCC packages ( esp the smaller ones ) are usefull, but the trend
is to TQFP and MLF, so socketing is going to get harder....

I can understand killing PLCC68 and PLCC84, but PLCC44 is still usefull.

Their new MachXO is Spec'd to 4.25V max.


> You know what would be real neat -- if somebody were to come up with a 
> generic 5 volt, 40-PIN DIP CPLD in a high enough density to emulate a 6502 
> or 6800 processor or the myriad of support parts that are no longer 
> available.   Ohhhh.... I'd give an arm and a leg for a cheap and reliable 
> source of this type of part!

The volumes for this might kill it as a product - I have seen BGA 
packages put onto DIP40 headers, which could solve your problem ?

-jg




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