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 132250

Article: 132250
Subject: Re: Resetting FPGA Without watch dog timer
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 May 2008 07:28:50 +1200
Links: << >>  << T >>  << A >>
ratemonotonic wrote:
> Hi all ,
> 
> I am devoloping software fro microblaze using XPS and I dont have
> enough resources for a watchdog timer.
> 
> I want to reset the FPGA after n number of error conditions have
> occured in software. Whats the most reliable way to reboot the Xilinx
> Spartan 3 FPGA?

That path pre-supposes the system is lame, but no so lame it
cannot run the Quality decision software.
ie it only gives partial coverage.

Common parts are Reset/Watchdog devices, in SOT23-5 packages,
and these will generate a repeating Reset Pulse on failure to
trigger faster than a certain rate. Some even have window-watchdogs.

You can, of course, still trigger this in SW, anytime you want, by 
turning off the trigger.

-jg


Article: 132251
Subject: Re: I cannot find how to map a "record type" in my ucf file.
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 19 May 2008 13:08:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 2:38=A0pm, Pablo <pbantu...@gmail.com> wrote:
> this is my code:
>
> entity Top_Module is
> =A0 =A0 =A0 =A0 port (
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 o_DSP0 =A0 =A0 =A0 =A0 =A0: out =A0 =A0 My=
RecordType
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 );
> end Top_Module;
>
> whe o_DSP0 is:
>
> type MyRecordType is record
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int4 =A0 =A0 =A0 =A0 =A0 =A0: std_logic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int5 =A0 =A0 =A0 =A0 =A0 =A0: std_logic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int6 =A0 =A0 =A0 =A0 =A0 =A0: std_logic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int7 =A0 =A0 =A0 =A0 =A0 =A0: std_logic;
> =A0 =A0 =A0 =A0 end record;
>
> ---------------
>
> How is o_DSP0 declared in ucf file?

Most likely the 'o_DSP0' signal will get synthesized to a 'flattened'
set of names like 'o_DSP0_int4', 'o_DSP0_int5', etc.  Check the output
of your synthesis result to find out how the record type signal
elements got renamed.

KJ

Article: 132252
Subject: Re: Resetting FPGA Without watch dog timer
From: ratemonotonic <niladri1979@gmail.com>
Date: Mon, 19 May 2008 13:55:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 May, 18:51, Peter Alfke <pe...@xilinx.com> wrote:
> On May 16, 1:25 pm, Peter Alfke <pe...@xilinx.com> wrote:
>
>
>
> > On May 16, 8:07 am, austin <aus...@xilinx.com> wrote:
>
> > > Rate,
>
> > > Why do you need to reset the FPGA after some number of software errors?
> > >  Won't the software errors just re-occur?  How does resetting
> > > (restarting) the FPGA affect the software?
>
> > > To start over, forgetting everything, the best way is to pull PROG
> > > (low).  Tying an output of the same FPGA to the PROG line input is not
> > > something we can easily recommend, as unless we really have it tested,
> > > that is a race condition (as the first thing that happens when PROG is
> > > pulled low, is all IOs go tristate!).
>
> > > I believe this works for some parts...and perhaps Peter will chime in
> > > and let me know which one(s).
>
> > > Austin
>
> > To re-configure, you must pull down PROG for a certain length of
> > time,expressed in microseconds.If you use one FPGA output to do this,
> > you face a dilemma: Once reconfiguration starts, every output is being
> > 3-stated, which violated the min PRG=Low time requirement.In older
> > parts, this self-triggering worked reliably "by design", since both
> > reconfiguration and 3-stating were controlled by a common latch. Once
> > set, there was no way to stop configuration.
> > This nice design was changed in some of the Virtex and probably also
> > in some of the Spartan parts, just because the rationale for the
> > previous design methodology was forgotten (its impact had never been
> > officially documented anyhow). I'll try to find out, once and for all,
> > which parts are designed which way.
> > In future parts we intend to re-institute the old design method, since
> > it offers one unbeatable advantage...
> > Peter Alfke
>
> In Spartan-3 and Spartan 3E you need an external delay.
> In Spartan3A and its derivatives (AN, DSP and future devices) the safe
> operation is guaranteed by design: just use one output to drive PROG
> Low.
> Virtex, Virtex-II and Virtex-4 need an external delay.
> Virtex-5 has an internal controller that can start re-configuration
> (see Config User Guide, page 145).
> Peter Alfke

Thanks peter ,it is very helpful to know. We have constructed a delay
circuit and it works fine.
ofcourse we dont realy want to reset the FPGA  in the real system. But
this will buy us valuable time , where we can
perfect the hardware.

BR
Rate

Article: 132253
Subject: Announcing Virtex 57!
From: austin <austin@xilinx.com>
Date: Mon, 19 May 2008 14:10:28 -0700
Links: << >>  << T >>  << A >>
John,

If you want some real entertainment:

http://www.pldesignline.com/showArticle.jhtml?articleID=207000972

Austin

Article: 132254
Subject: HELP: a Funny asynchronous input design
From: Aiken <aikenpang@gmail.com>
Date: Mon, 19 May 2008 15:10:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
input: Asynchronous, non-fix width, non-fix frequeny(but equal or
smaller than 30 Mhz), something like random fast signal coming in.
System clock is only 40MHz,

What can I latch the "rising" edge of the input and synchronize it and
don't get into big trouble of Metastability?
Since the input freq is very near the System clock and Asynchronous
don't have a clock signal coming in.
is it possible that connecting the input signal directly to FF clock
then following with a negative clk edge FF then positive clk edge FF?
will it make any trouble and how to solve it?

Article: 132255
Subject: Re: Stratix IV Announced
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 20 May 2008 10:11:33 +1200
Links: << >>  << T >>  << A >>
John Adair wrote:
> Altera have put out a press release announcing Stratix IV. Handbook
> http://www.altera.com/literature/hb/stratix-iv/stx4_5v4.pdf.
> Interestingly it's gone 40nm and does not appear to have a true 3.3V
> compatability so buy your shares in manufacurers of bus switches now.

Only partially.
They do not state a Typical 3.3V, but they do say this

The Abs Max spec 3.75V,
V @ IO spec 3.6V


The overshoot even gives a rather strange/interesting Volts/Time
plot, where 4V overshoot is allowed 100% time, but 4.45V is
limited to 1% of the time.

What they do NOT say, is what happens if the 4.45V is there for 2% of 
the time :)

Does the device
a) Fry immediately it exceeds the 1.080% time allowance ?
(Their precision is impressve!)
b) Think about it for a while, then Fry ?
c) Suffer a gradual leakage degradation, so it exceeds
the 10uA spec, after the Volt-Time threshold.
d) If c) then can the device fail, or just drift out of
spec, and does that drift have a limit ?


Lifetime of device ? Err ?! - They give an example of 10 years,
but what should one do for a 5 year, or 20 year design life ?

There is some underlying mechanism they are trying to spec here,
but would it not make more sense, to identify that mechanism,
than use this rather silly (partial) table, that raises more
questions than it answers ?

-jg




Article: 132256
Subject: Re: 2-bit Pseudo Random Number Generator
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 19 May 2008 18:36:20 -0400
Links: << >>  << T >>  << A >>
Clemens wrote:

> A different seed for each power-up would have been nice.

Here's a method I've used for this in the past:

Create a ring oscillator that can be stopped by some other bit. The ring 
oscillator drives a 2-bit ripple counter.

Once the FPGA clock starts up, count off say 1 second's worth pulses of 
your high speed system clock and then disable the ring oscillator. The 
ripple counter will now have your 4-bit random value.

This method relies on slight differences in the ring osc rate due to 
heating, etc. to add up over 1 second at startup. You might need to 
experiment with adding buffers (and make sure the tools don't remove 
them) and such to make sure the ring osc rate is not too high.

-Jeff

Article: 132257
Subject: bizarre state machine behavior
From: Jon Elson <elson@wustl.edu>
Date: Mon, 19 May 2008 17:36:36 -0500
Links: << >>  << T >>  << A >>
Hello,

I ran into a bizarre state machine problem last week.  I had a fairly 
simple state machine written in VHDL, with an enumerated type and 5 
states.  The code is of the form :

if clock'event and clock='1' then
    . . .
   if state = a then
     if inputa = '1' then
       state <= b;
       outputa <= '1';
     end if;
   end if;

   if state = b then
   . . .

the whole thing is synchronous, running at 40 MHz on a Spartan 2E, 
except a couple external inputs such as the "inputa" above.
What I was seeing was the state machine locking up, so I added a process 
to decode the valid states and send them to LEDs.  I could see that the 
lockups left signal state in some non-valid condition, ie. NOT one of 
the enumerated values of the type.

I theorized it was encoding this as "one hot" as the software was set.
So, I forced the enumeration to have specific binary-coded values, and
enumerated all 8 possible codes, providing an if for the unused states 
to go back to the reset state.  This fixed the problem as far as I can 
tell.  I think this is telling me that in the "one hot" mode, it was 
somehow getting more than one bit set true at a time.

Well, I was careful to set up the if's for each specific state to have 
nested ifs in such a way so that any combination of input conditions 
could only satisfy one of the lowest nested ifs.  So, I just can't 
figure out how it could possibly set more than one bit hi at a time.
There was a state where it could assign 2 different states values to 
state, depending on the ifs.  But, if all the ifs were nested, it could 
never try to assign both values at the same time on the same clock.
But, that seems to be what was happening.  The software is ISE 4.2
(I am still supporting some 5V Spartan stuff, and I'm also cheap).

Any hints about what was happening would be greatly appreciated!

Jon


Article: 132258
Subject: Re: bizarre state machine behavior
From: Rob Gaddi <rgaddi@technologyhighland.com>
Date: Mon, 19 May 2008 15:46:25 -0700
Links: << >>  << T >>  << A >>
Jon Elson wrote:

 > <snip>
> the whole thing is synchronous, running at 40 MHz on a Spartan 2E, 
> except a couple external inputs such as the "inputa" above.
 > <snip>

That right there could be your problem.  If those inputs aren't 
synchronous then you could get into some trouble if they change just 
before a clock edge happens.  Some of your state machine flops get the 
new message, some get the old one, and you've magically got an illegal 
state.

Can you register those signals for a clock before you use them?

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 132259
Subject: Re: Incorporating FPGAs on PCBs
From: PFC <lists@peufeu.com>
Date: Tue, 20 May 2008 01:15:29 +0200
Links: << >>  << T >>  << A >>

> 	I need to interconnect two or four FPGAs on a PCB, and I am looking

	Why not just a bigger FPGA ?

> at the prospect of designing these boards myself. If any one has done
> this, I would be grateful if you could provide some pointers,
> especially links to websites that have this information. I would
> probably be using the Xilinx Virtex II

	A message of hope : I just built a proto with a Spartan-3E 500, SDRAM,  
Ethernet MAC, had never designed a 4 layer board before, and it worked.  
Everything works. The only problem was the JTAG which turned out to be a  
faulty parallel cable. Ironically hand soldering the PQ208 was a lot  
easier (5 minutes) than debugging the JTAG (two days).

> 	I don’t know how to start this – but I have a few questions. Is it
> possible for me to simulate the setup between FPGAs connected on a PCB
> board. Or is it possible for me to bread board the FPGA – I have not

	Bread board ? Nope. Fire up Altium, make a PCB, and use for instance  
protoexpress.com, or get a readymade Spartan board from Enterpoint, etc.
	Actually you don't really need breadboarding... the FPGA will work. It's  
your switchmode regulator and other crap that won't work.

> heard of this though. I have looked at the manual of the Virtex II,
> and there are a large numbers of pins – I have yet to figure out which
> pins I need to power at the minimum to get this to work.

	Powering all the power pins seems like a good idea...

> So I don’t
> want to start laying out a PCB Board immediately.
>
> 	I would be requiring significant on board communication – but I don’t
> think I need the Rocket IOs that are available with Virtex4 – the
> simple LVDS would do for me I guess. Is there a way for me to test
> this aspect before actually putting it on the PCB??

	As long as you have a FPGA and traces that go to it, you can make it work  
;)
	Sleeping with the xilinx datasheets is a good idea too.

Article: 132260
Subject: Re: bizarre state machine behavior
From: Jeff Cunningham <jcc@sover.net>
Date: Mon, 19 May 2008 19:24:46 -0400
Links: << >>  << T >>  << A >>
Rob Gaddi wrote:
> Jon Elson wrote:
> 
>  > <snip>
>> the whole thing is synchronous, running at 40 MHz on a Spartan 2E, 
>> except a couple external inputs such as the "inputa" above.
>  > <snip>
> 
> That right there could be your problem.  If those inputs aren't 
> synchronous then you could get into some trouble if they change just 
> before a clock edge happens.  Some of your state machine flops get the 
> new message, some get the old one, and you've magically got an illegal 
> state.
> 
> Can you register those signals for a clock before you use them?

In addition to registering all inputs, you also should make sure that 
the state machine is initialized with a synchronous reset after your 
DLLs have locked.

-Jeff

Article: 132261
Subject: Re: bizarre state machine behavior
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 20 May 2008 00:39:02 +0100
Links: << >>  << T >>  << A >>
"Jon Elson" <elson@wustl.edu> wrote in message 
news:483200F4.3090002@wustl.edu...
>
> the whole thing is synchronous, running at 40 MHz on a Spartan 2E, except 
> a couple external inputs such as the "inputa" above.
>

Hi Jon,
That's your problem! You have a one hot state machine with five states. This 
is implemented as five flipflops(FF). Your external inputs are asynchronous, 
and so if their transitions happen to be close to the clock transition, you 
wil have a race condition where the signal can get to one/some FF/s, but not 
others.
Try this link http://en.wikipedia.org/wiki/Race_condition
Cheers, Syms.
p.s. For completeness, I should mention there is a difference between race 
hazards and metastability. Your circuit can suffer from both, but in your 
case the race condition is many orders of magnitude more observable than the 
'm' word! See CAF passim!



Article: 132262
Subject: Re: Stratix IV Announced
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Tue, 20 May 2008 02:03:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
They've also released Hardcopy-IV, including serdes and PCI-e.  Why bother
with ASICs...

-- 
/*  jhallen@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]]);}

Article: 132263
Subject: Re: synthesis...
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Tue, 20 May 2008 03:04:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-05-20, fazulu deen <fazulu.vlsi@gmail.com> wrote:
> I would like to know how these statements(for,while,do while) are
> implemented as logic design(EDIF and constraints) in FPGA device?? .
>
> Though FOR loop is synthesizable , it is always advised that FOR loops
> are not to be used in RTL coding. This is because it consumes lot of
> resources (like area etc)whether XST will not optimize it before
> targetting to FPGA device???

There is nothing magical with for and while loops in a synthesized
design. The synthesizer will simply unroll the loop for you. If
you know this you should easily be able to tell if a for loop is
applicable in your particular case.

For example, if you would like to write something like this in
Verilog a for loop is very suitable to do it:


// Bit reverse the signal:
always @* begin
  foo[0] = bar[63];
  foo[1] = bar[62];
  foo[2] = bar[61];
  // Kind of boring to write this without a for loop...


However, lets say that you have an array with 512 values in a 
memory and you want to calculate the sum of all values:

always @* begin
   sum = 0
   for(i=0; i < 512; i = i + 1) begin
      sum = sum + mem[i];
   end
end

This is going to be hugely expensive in terms of hardware to
implement as you will end up with 512 adders and force your
memory to be implemented using flip-flops instead of a blockram.
In this case it is probably a much better idea to write a small
state machine to sum the values. It will take around 512 clock
cycles unless you do something clever like reading several values
at a time, but the footprint will be much more reasonable.

/Andreas

Article: 132264
Subject: Re: HELP: a Funny asynchronous input design
From: Peter Alfke <alfke@sbcglobal.net>
Date: Mon, 19 May 2008 20:24:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 3:10=A0pm, Aiken <aikenp...@gmail.com> wrote:
> input: Asynchronous, non-fix width, non-fix frequeny(but equal or
> smaller than 30 Mhz), something like random fast signal coming in.
> System clock is only 40MHz,
>
> What can I latch the "rising" edge of the input and synchronize it and
> don't get into big trouble of Metastability?
> Since the input freq is very near the System clock and Asynchronous
> don't have a clock signal coming in.
> is it possible that connecting the input signal directly to FF clock
> then following with a negative clk edge FF then positive clk edge FF?
> will it make any trouble and how to solve it?

Synchronizing a 30 MHz signal with a roughly 40 MHz clock will
generate an uncontrollable extra metastable delay of a few ns
occasionally.
But an extra 4 ns only once per many thousand years, statistically.
You really do not have to worry about metastability.
At ten times higher frequencies, you would run into problems...
Se my Xilinx appnote XAPP094...
Peter Alfke

Article: 132265
Subject: Re: Problem with conversions.vhd
From: rickman <gnuarm@gmail.com>
Date: Mon, 19 May 2008 21:22:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 7:30 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 18 May 2008 11:25:15 +0100, Jonathan Bromley
>
>
>
> <jonathan.brom...@MYCOMPANY.com> wrote:
> >On Sun, 18 May 2008 08:22:24 +0100, Brian Drummond wrote:
>
> >>I wrote: VHDL is not a dynamically typed language; you can't stretch and
> >>shrink subtypes e.g. ranges during run time.
>
> >>Which makes sense if you think about its orientation as a hardware
> >>language; it is difficult to stretch and shrink registers or counters
> >>after synthesis.
>
> >Yes, but subprograms (procedures and functions) are dynamically
> >elaborated: all their arguments, and their local variables, are
> >constructed dynamically at the moment of invocation.  This is
> >what allows you to handle unconstrained arguments so elegantly.
> >For synthesis, the tool must convince itself that each subprogram
> >call is in a context in which the tool can statically determine
> >what will get elaborated; in other words, you effectively get
> >a new static instance of each subprogram for each distinct
> >invocation.
>
> Absolutely; I didn't mean anything different.
>
> I possibly misread Rickman's post; that he was re-calling the function
> for a different value of the same variable in the same instance of the
> same process. Which is not clear is the case.

That's a lot of sames... I'm not sure so here is the line that was
causing the error, at least I think this is it.

	  	report "Read " &
	  			" Addr " & to_hex_str(AddrWd, 2) &
	  			" Read data " & to_hex_str(DataWd, 4) &
	  			CR & LF severity NOTE;

As a work around I just converted the SLVs to ints like this,
to_int(AddrWd) and a different function was invoked that works
differently.


> Otherwise, I agree, it looks like a bug.
>
> I have found problems with ISE incorrectly synthesising different calls
> to a procedure in the same process so a similar bug in their simulator
> is credible.
>
> >Alternatively, there may be other ways to get your
> >type conversion, saving you the trouble of fighting
> >a possibly buggy FMF package.  Converting a SLV to
> >its hex text representation is easy enough.
>
> That's why I was suggesting a static range, and using the parameter's
> length attribute to determine the number of digits.

The function *does* use the parameter's length attribute to set the
number of digits.  Maybe I misunderstand what you mean.  Here is the
initial code of the function.

    function to_hex_str(x          : std_logic_vector;
                        rtn_len    : natural      := 0;
                        justify    : justify_side := right;
                        basespec   : b_spec       := yes) return
string is
      -- will return x'length/4
      variable nxt : positive := nextmultof(x'length,4);
      variable int : std_logic_vector(1 to nxt):= (others => '0');
      variable ptr : positive range 1 to (nxt/4)+1 := 1;
      variable r   : string(1 to nxt/4):=(others=>'$');
      subtype slv4 is std_logic_vector(1 to 4);
      variable slv4_val : slv4;
    begin

The length of the input string 'x' is used to define nxt which in tern
is used to define everything else.

I still don't have another simulator running, but I might later this
week.

Rick

Article: 132266
Subject: V4 - VTRX & AVCCAUXRX
From: akshat <mailtoakshat@gmail.com>
Date: Mon, 19 May 2008 22:26:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

DS302 - Pg 11, Table 12, Note 1 says "The maximum VTRX is 1.26V when
bypassing the internal AC coupled VICM. VTRX must be less than or
equal to AVCCAUXRX".

How is VTRX (Termination) related to AVCCAUXRX (Rocket IO) ?

If this guideline is not followed, what effects it might have ?


Thanks
Akshat

Article: 132267
Subject: synthesis...
From: fazulu deen <fazulu.vlsi@gmail.com>
Date: Mon, 19 May 2008 22:42:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
hai,

I learned from the Xilinx manual that for,while do statements are
synthesized in XST..

I would like to know how these statements(for,while,do while) are
implemented as logic design(EDIF and constraints) in FPGA device?? .

Though FOR loop is synthesizable , it is always advised that FOR loops
are not to be used in RTL coding. This is because it consumes lot of
resources (like area etc)whether XST will not optimize it before
targetting to FPGA device???

As wait() is not supported for synthesis wat should i use instead of
wait()??

regards,
faz

Article: 132268
Subject: Re: Problem with Scheduler in Xilkernel.
From: Jespr <DonMadsen@gmail.com>
Date: Mon, 19 May 2008 23:41:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
Year I did, here is my MHS file:

PARAMETER VERSION = 2.1.0


 PORT fpga_0_RS232_DCE_RX_pin = fpga_0_RS232_DCE_RX, DIR = I
 PORT fpga_0_RS232_DCE_TX_pin = fpga_0_RS232_DCE_TX, DIR = O
 PORT fpga_0_RS232_DTE_RX_pin = fpga_0_RS232_DTE_RX, DIR = I
 PORT fpga_0_RS232_DTE_TX_pin = fpga_0_RS232_DTE_TX, DIR = O
 PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ =
50000000
 PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 1, SIGIS = RST


BEGIN proc_sys_reset
 PARAMETER INSTANCE = proc_sys_reset_0
 PARAMETER HW_VER = 2.00.a
 PARAMETER C_EXT_RESET_HIGH = 1
 PORT Slowest_sync_clk = sys_clk_s
 PORT Dcm_locked = Dcm_all_locked
 PORT Ext_Reset_In = sys_rst_s
 PORT MB_Reset = mb_reset
 PORT Bus_Struct_Reset = sys_bus_reset
 PORT MB_Debug_Sys_Rst = Debug_SYS_Rst
END

BEGIN microblaze
 PARAMETER HW_VER = 7.00.a
 PARAMETER INSTANCE = microblaze_0
 PARAMETER C_INTERCONNECT = 1
 PARAMETER C_DEBUG_ENABLED = 1
 PARAMETER C_AREA_OPTIMIZED = 1
 BUS_INTERFACE DLMB = dlmb
 BUS_INTERFACE ILMB = ilmb
 BUS_INTERFACE DPLB = mb_plb
 BUS_INTERFACE IPLB = mb_plb
 BUS_INTERFACE DEBUG = microblaze_0_dbg
 PORT RESET = mb_reset
 PORT INTERRUPT = Interrupt
END

BEGIN plb_v46
 PARAMETER INSTANCE = mb_plb
 PARAMETER HW_VER = 1.00.a
 PORT PLB_Clk = sys_clk_s
 PORT SYS_Rst = sys_bus_reset
END

BEGIN bram_block
 PARAMETER INSTANCE = lmb_bram
 PARAMETER HW_VER = 1.00.a
 BUS_INTERFACE PORTA = ilmb_port
 BUS_INTERFACE PORTB = dlmb_port
END

BEGIN lmb_bram_if_cntlr
 PARAMETER INSTANCE = ilmb_cntlr
 PARAMETER HW_VER = 2.10.a
 PARAMETER C_BASEADDR = 0x00000000
 PARAMETER C_HIGHADDR = 0x00003fff
 BUS_INTERFACE SLMB = ilmb
 BUS_INTERFACE BRAM_PORT = ilmb_port
END

BEGIN lmb_v10
 PARAMETER INSTANCE = ilmb
 PARAMETER HW_VER = 1.00.a
 PORT LMB_Clk = sys_clk_s
 PORT SYS_Rst = sys_bus_reset
END

BEGIN lmb_bram_if_cntlr
 PARAMETER INSTANCE = dlmb_cntlr
 PARAMETER HW_VER = 2.10.a
 PARAMETER C_BASEADDR = 0x00000000
 PARAMETER C_HIGHADDR = 0x00003fff
 BUS_INTERFACE SLMB = dlmb
 BUS_INTERFACE BRAM_PORT = dlmb_port
END

BEGIN lmb_v10
 PARAMETER INSTANCE = dlmb
 PARAMETER HW_VER = 1.00.a
 PORT LMB_Clk = sys_clk_s
 PORT SYS_Rst = sys_bus_reset
END

BEGIN mdm
 PARAMETER INSTANCE = debug_module
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_MB_DBG_PORTS = 1
 PARAMETER C_USE_UART = 1
 PARAMETER C_UART_WIDTH = 8
 PARAMETER C_BASEADDR = 0x84400000
 PARAMETER C_HIGHADDR = 0x8440ffff
 BUS_INTERFACE SPLB = mb_plb
 BUS_INTERFACE MBDEBUG_0 = microblaze_0_dbg
 PORT Debug_SYS_Rst = Debug_SYS_Rst
END

BEGIN clock_generator
 PARAMETER INSTANCE = clock_generator_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_EXT_RESET_HIGH = 1
 PARAMETER C_CLKIN_FREQ = 50000000
 PARAMETER C_CLKOUT0_FREQ = 50000000
 PARAMETER C_CLKOUT0_PHASE = 0
 PARAMETER C_CLKOUT0_GROUP = NONE
 PORT CLKOUT0 = sys_clk_s
 PORT CLKIN = dcm_clk_s
 PORT LOCKED = Dcm_all_locked
 PORT RST = net_gnd
END

BEGIN xps_uartlite
 PARAMETER INSTANCE = RS232_DTE
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BAUDRATE = 9600
 PARAMETER C_DATA_BITS = 8
 PARAMETER C_ODD_PARITY = 0
 PARAMETER C_USE_PARITY = 0
 PARAMETER C_SPLB_CLK_FREQ_HZ = 50000000
 PARAMETER C_BASEADDR = 0x84020000
 PARAMETER C_HIGHADDR = 0x8402ffff
 BUS_INTERFACE SPLB = mb_plb
 PORT RX = fpga_0_RS232_DTE_RX
 PORT TX = fpga_0_RS232_DTE_TX
END

BEGIN xps_uartlite
 PARAMETER INSTANCE = RS232_DCE
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BAUDRATE = 9600
 PARAMETER C_DATA_BITS = 8
 PARAMETER C_ODD_PARITY = 0
 PARAMETER C_USE_PARITY = 0
 PARAMETER C_SPLB_CLK_FREQ_HZ = 50000000
 PARAMETER C_BASEADDR = 0x84000000
 PARAMETER C_HIGHADDR = 0x8400ffff
 BUS_INTERFACE SPLB = mb_plb
 PORT RX = fpga_0_RS232_DCE_RX
 PORT TX = fpga_0_RS232_DCE_TX
END

BEGIN xps_bram_if_cntlr
 PARAMETER INSTANCE = xps_bram_if_cntlr_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_SPLB_NATIVE_DWIDTH = 32
 PARAMETER C_BASEADDR = 0x84414000
 PARAMETER C_HIGHADDR = 0x84417fff
 BUS_INTERFACE SPLB = mb_plb
 BUS_INTERFACE PORTA = xps_bram_if_cntlr_0_PORTA
END

BEGIN bram_block
 PARAMETER INSTANCE = bram_block_0
 PARAMETER HW_VER = 1.00.a
 BUS_INTERFACE PORTA = xps_bram_if_cntlr_0_PORTA
END

BEGIN xps_timer
 PARAMETER INSTANCE = delay
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BASEADDR = 0x84410800
 PARAMETER C_HIGHADDR = 0x844109ff
 BUS_INTERFACE SPLB = mb_plb
 PORT Interrupt = delay_Interrupt
END

BEGIN xps_intc
 PARAMETER INSTANCE = xps_intc_0
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BASEADDR = 0x84412000
 PARAMETER C_HIGHADDR = 0x844121ff
 BUS_INTERFACE SPLB = mb_plb
 PORT Intr = delay_Interrupt
 PORT Irq = Interrupt
END


Article: 132269
Subject: Re: SKEW greater than Time period of CLK
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 20 May 2008 00:06:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 19 Mai, 08:28, kris2552 <muralee.vkris...@gmail.com> wrote:
> could anybody please explain me ....whether is there any chance of
> clock skew being greater than or equal to the timeperiod of the clock?
> If so,what are the effects? Any explaination would be deeply
> appreciated.....

a)
Please answer yourself, what would be necessary to prevent Clk-Skew
beeing greater or equal the timeperiode of clock.
b)
A simplified calculation for max clk frequency is
Fmax=1/(signal_delay + skew_delta)
You should be aware that skew_delta may be >0 or <0.

bye Thomas

Article: 132270
Subject: Re: I cannot find how to map a "record type" in my ucf file.
From: Pablo <pbantunez@gmail.com>
Date: Tue, 20 May 2008 00:13:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks


Article: 132271
Subject: Re: Stratix IV Announced
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 20 May 2008 00:28:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jim

They say somewhere I saw that 3.3V operation the bank voltage is
recommended to be 3.0V so that the protection diodes work. It's
probably less of a problem the way thay have done it than what Xilinx
did in the early Spartan-3 in that it can take a 3.3V driven input.
There s not a lot of margin though if all the power supply tolerances
are taken into account.

John Adair
Enterpoint Ltd.

On 19 May, 23:11, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> John Adair wrote:
> > Altera have put out a press release announcing Stratix IV. Handbook
> >http://www.altera.com/literature/hb/stratix-iv/stx4_5v4.pdf.
> > Interestingly it's gone 40nm and does not appear to have a true 3.3V
> > compatability so buy your shares in manufacurers of bus switches now.
>
> Only partially.
> They do not state a Typical 3.3V, but they do say this
>
> The Abs Max spec 3.75V,
> V @ IO spec 3.6V
>
> The overshoot even gives a rather strange/interesting Volts/Time
> plot, where 4V overshoot is allowed 100% time, but 4.45V is
> limited to 1% of the time.
>
> What they do NOT say, is what happens if the 4.45V is there for 2% of
> the time :)
>
> Does the device
> a) Fry immediately it exceeds the 1.080% time allowance ?
> (Their precision is impressve!)
> b) Think about it for a while, then Fry ?
> c) Suffer a gradual leakage degradation, so it exceeds
> the 10uA spec, after the Volt-Time threshold.
> d) If c) then can the device fail, or just drift out of
> spec, and does that drift have a limit ?
>
> Lifetime of device ? Err ?! - They give an example of 10 years,
> but what should one do for a 5 year, or 20 year design life ?
>
> There is some underlying mechanism they are trying to spec here,
> but would it not make more sense, to identify that mechanism,
> than use this rather silly (partial) table, that raises more
> questions than it answers ?
>
> -jg


Article: 132272
Subject: Re: my Spartan-4 wishlist
From: PFC <lists@peufeu.com>
Date: Tue, 20 May 2008 10:46:37 +0200
Links: << >>  << T >>  << A >>
On Mon, 03 Mar 2008 20:40:07 +0100, Antti <Antti.Lukats@googlemail.com>  
wrote:

> here it is:
>
> 1) devices densities like in Spartan-3 (50..5000)
> 2) devices packages like Spartan-3E (including QN132 !) or better
> (microBGA 6x6 mm?)
> 3) all good features of S3A/AN !!
> 4) design security with OTP encryption key (like Lattice ECP2)
> 5) other features as already planned by Xilinx


	Here's mine :

	* Easy one :

	- Schmitt trigger on the TCK line

	* New packages to make prototyping easier and to make the chips easier to  
use on simpler boards that are less expensive, would translate into costs  
saving for small / simple systems, and possibly more sales from Xilinx !  
Examples :

	- Self-centering BGA : put a through-hole pin in each of the corners of  
the BGA, the PCB designer makes 4 holes on the PCB, and the part now can  
be placed by a drunk intern, instead of a megabuck BGA placing robot. No,  
strike that, make it only 3 holes, so you can't put it the wrong way in.

	- PQ208 : put thermal pad below connected to GND, remove all GND pins  
 from package ; put other smaller "thermal pads" for the power supplies and  
get rid of the supply pins, you get 50 more IO on the package.

	- BGA usable on a 4-layer board with standard specs (6/6 track and  
standard holes), instead of 6-layer with super small holes :
	Solution 1 : remove pins in a cross pattern for escaping with much less  
vias
	Solution 2 : Two exterior rows of pins @ 1mm pitch or even 0.8mm pitch,  
and all internal pins at 1.27mm pitch, to allow vias between the pins even  
on a cheap PCB process
	Interior pins :

	* A bit more difficult :

	- FPGAs shouldn't have input-only pins... the spartan-3E is a bit  
annoying for this... I know it's a compromise with the IOBs space on die,  
then a better solution would be a simpler IOB, supporting less features  
(like only LVCMOS output from the bank's voltage, not all the IOStandards)  
but please get rid of those input-only pins
	- If you can't get rid of the input-only pins, on the BGA package put  
them all in the internal balls close to the chip's center so if the  
designer doesn't need them he can forget them and save on layers...
	- more decoupling caps inside the package

	* Other :

	Hard SDRAM controller (or DDR) core in the chip and stacked SDRAM chip in  
the package, or multi chip module... you get the idea ;)
	ARM core

	Hey it was supposed to be a wishlist right ? In all of those if I just ge  
a more noise-tolerant TCK input I'll be happy.

Article: 132273
Subject: Re: 2-bit Pseudo Random Number Generator
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 20 May 2008 09:50:50 +0100
Links: << >>  << T >>  << A >>

"Jeff Cunningham" <jcc@sover.net> wrote in message 
news:483200e3$0$11170$4d3efbfe@news.sover.net...
> Clemens wrote:
>
>> A different seed for each power-up would have been nice.
>
> Here's a method I've used for this in the past:
>
> Create a ring oscillator that can be stopped by some other bit. The ring 
> oscillator drives a 2-bit ripple counter.
>
> Once the FPGA clock starts up, count off say 1 second's worth pulses of 
> your high speed system clock and then disable the ring oscillator. The 
> ripple counter will now have your 4-bit random value.
>
> This method relies on slight differences in the ring osc rate due to 
> heating, etc. to add up over 1 second at startup. You might need to 
> experiment with adding buffers (and make sure the tools don't remove them) 
> and such to make sure the ring osc rate is not too high.
>
> -Jeff

Hi Jeff,

I've heard that ring oscillators can phase lock to other clocks on the same 
die. What did you find? I came across  this link that gives some insights 
into the pitfalls.
http://warmcat.com/_wp/

Now, this guy really knows how to do random!
http://inventgeek.com/Projects/alpharad/overview.aspx

Cheers, Syms.



Article: 132274
Subject: Re: Problem with Scheduler in Xilkernel.
From: Guy Eschemann <Guy.Eschemann@gmail.com>
Date: Tue, 20 May 2008 02:30:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
You could try to step through those functions with the debugger (GDB):
compile the libraries with -g and -O0 options, set a breakpoint in
xilkernel_main(), and set into the xilkernel_init() function.
See also XAPP1037 for a really nice introduction to debugging
Microblaze programs.
Hope this helps,
Guy.



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